Add badges, fix spello, and test unresolvable dials

[anacrolix]

I've picked out the parts of #67 that I'm happy with. @Stebalien is the best course of action to remove that go file if it breaks gx? @petroav I'd prefer any tests of Dial and Listen use the existing style with testify, and port zero to allow parallel tests, and -count > 1 without weird behaviour.

[petroav]

@anacrolix thank you for the follow up!

Is testify a library I should be using when writing tests in for libp2p packages?

-count > 1 without weird behaviour

Not sure what this means, can you clarify?

The Listen() and Dial() methods as written in testDialFromListeningPort do not exercise the code in the go-reuseport package but are instead called on a locally created ListenConfig. Why not call the wrapper methods in interface.go?

Can explain why you think ResolveAddr() should not be explicitly tested? The next repo I planned to contribute tests to is go-sockaddr which contains a number of methods similar to ResolveAddr(). I was planning on testing those methods in a similar way.

[Stebalien]

Is testify a library I should be using when writing tests in for libp2p packages?

It's a library that @anacrolix chose to use here. We don't use it anywhere else (that I know of) and haven't discussed switching over to it.

@anacrolix would you like to file an issue in go-libp2p proposing that we make it our go-to testing framework? I believer @marten-seemann prefers ginkgo/gomega.

[anacrolix]

@petroav Your tests used explicit ports on localhost. They may be flaky when tests are executed in parallel, or multiple times. The Listen and Dial methods are at this point only there for backward compatibility (consumers should be using Control directly from Go 1.11 onwards). If they're worth testing to increase arbitrary code coverage metrics, it should be done by passing in the listen and dial functions to testDialFromListeningPort which correctly avoids port collisions per above and avoids repeating the error handling all over the place.

I'm not sure ResolveAddr even belongs in this package. I've opened #69 for it. Perhaps you'll have more insight after looking at go-sockaddr?

@Stebalien I don't want to standardize on testing suites unless someone has an issue with something. There's too much bike-shedding, and personal preference should be allowed.

[anacrolix]

This PR should be merged. Further additions are open to further discussion, but there's no reason not to merge this at this point.

[raulk]

We might want to skip the tests if SO_REUSEPORT is not available in the host OS; currently we error (but this PR doesn't touch that).

I also think there are valuable test cases in #67 we might want to port over (although I think #67 dropped IPv6 testing?).

OK with introducing testify, but I would like us to agree on a testing toolkit to avoid random sprouting across the codebase. @anacrolix – could you open an issue on libp2p/go-libp2p to discuss?

[Stebalien]

I don't want to standardize on testing suites unless someone has an issue with something. There's too much bike-shedding, and personal preference should be allowed.

You were asking @petroav to use it so I figured you might want to propose that it be used everywhere. I hind sight, I guess you just meant "use it here" because that's what all the other tests are doing (makes sense).