libp2p-swarm-test: Introduce crate for shared testing abstractions

[thomaseizinger]

Description

This patch-set introduces libp2p-swarm-test. I am putting it up as a draft for now. In case people like it, I can move forward and port more of our tests to it / extend it on the way.

cc @melekes

Links to any relevant issues

Closes #2884.

Open Questions

• Should this testing crate also pull together utilities like ArbitraryPeerId?
• ~Can we make the Swarm::new_ephemeral API any better? At the moment it only allows to configure the underlying transport but the authentication and muxer are hardcoded. I don't want to introduce any more parameters because it will get too verbose and there wouldn't be a benefit in having the function in the first place. Should we perhaps introduce a dedicated SwarmBuilder for our tests that start with some reasonable test defaults, like a MemoryTransport?~
• ~Trying to port the new harness to libp2p-ping, I noticed that we'd lose the MuxerChoice as part of the prop test. If we go forward with the SwarmBuilder extension idea, we could make a function there that cycles through various muxers and authentication algorithms to make sure things work across various stacks. I am not sure it is worth it though to be honest.~

Open tasks

• Port to more crates

Change checklist

• [x] I have performed a self-review of my own code ~- [ ] I have made corresponding changes to the documentation~ ~- [ ] I have added tests that prove my fix is effective or that my feature works~ ~- [ ] A changelog entry has been made in the appropriate crates~

[mxinden]

Should this testing crate also pull together utilities like ArbitraryPeerId?

I am guessing that defining Arbitrary on PeerId directly under the cfg[test] doesn't expose outside of the crate. Is that correct?

[mxinden]

• Can we make the Swarm::new_ephemeral API any better? At the moment it only allows to configure the underlying transport but the authentication and muxer are hardcoded. I don't want to introduce any more parameters because it will get too verbose and there wouldn't be a benefit in having the function in the first place. Should we perhaps introduce a dedicated SwarmBuilder for our tests that start with some reasonable test defaults, like a MemoryTransport?

I think all our non Transport tests should use the MemoryTransport, thus I am in favor of this default.

[mxinden]

Trying to port the new harness to libp2p-ping, I noticed that we'd lose the MuxerChoice as part of the prop test. If we go forward with the SwarmBuilder extension idea, we could make a function there that cycles through various muxers and authentication algorithms to make sure things work across various stacks. I am not sure it is worth it though to be honest.

I still have to put more thoughts into this, though as an intuition I suggest that a test only tests one thing. E.g. the libp2p-ping tests test libp2p-ping and not some permutation of different transports and muxers. I think that should happen in a separate dedicated test.

[thomaseizinger]

Should this testing crate also pull together utilities like ArbitraryPeerId?

I am guessing that defining Arbitrary on PeerId directly under the cfg[test] doesn't expose outside of the crate. Is that correct?

That is correct.

• Can we make the Swarm::new_ephemeral API any better? At the moment it only allows to configure the underlying transport but the authentication and muxer are hardcoded. I don't want to introduce any more parameters because it will get too verbose and there wouldn't be a benefit in having the function in the first place. Should we perhaps introduce a dedicated SwarmBuilder for our tests that start with some reasonable test defaults, like a MemoryTransport?

I think all our non Transport tests should use the MemoryTransport, thus I am in favor of this default.

Cool, that makes this simpler :)

Trying to port the new harness to libp2p-ping, I noticed that we'd lose the MuxerChoice as part of the prop test. If we go forward with the SwarmBuilder extension idea, we could make a function there that cycles through various muxers and authentication algorithms to make sure things work across various stacks. I am not sure it is worth it though to be honest.

I still have to put more thoughts into this, though as an intuition I suggest that a test only tests one thing. E.g. the libp2p-ping tests test libp2p-ping and not some permutation of different transports and muxers. I think that should happen in a separate dedicated test.

Yeah I am tending towards the same. We should have a good muxer test harness instead!

[mxinden]

Should this testing crate also pull together utilities like ArbitraryPeerId?

I am guessing that defining Arbitrary on PeerId directly under the cfg[test] doesn't expose outside of the crate. Is that correct?

That is correct.

That is unfortunate. In that case, I am in favor of providing an ArbitraryPeerId from this new crate.

[thomaseizinger]

Should this testing crate also pull together utilities like ArbitraryPeerId?

I am guessing that defining Arbitrary on PeerId directly under the cfg[test] doesn't expose outside of the crate. Is that correct?

That is correct.

That is unfortunate. In that case, I am in favor of providing an ArbitraryPeerId from this new crate.

Now that we have quickcheck-ext, should it perhaps go in there?

[mxinden]

@thomaseizinger let me know once I should be taking another look here.

[thomaseizinger]

@libp2p/rust-libp2p-maintainers Please have another look to make sure this goes into the right direction! :)

[mxinden]

@libp2p/rust-libp2p-maintainers Please have another look to make sure this goes into the right direction! :)

Right direction from my side.

[mxinden]

Still interested to get this merged @thomaseizinger! Writing a tiny protocol right now where this would come in handy for testing.

[thomaseizinger]

Still interested to get this merged @thomaseizinger! Writing a tiny protocol right now where this would come in handy for testing.

Ah yes, me too. I'd prefer if we port the entire workspace over to this though which means there is still quite a bit of work to be done before we can merge it.

[thomaseizinger]

I'll see to spend some cycles on it soon.