Marteen is the core maintainer of libp2p ‣
The testing story around libp2p is mostly unit-tests, some come back from 4 - 5 years ago during the split from IPFS.
There is a job in go-ipfs that will more or less test libp2p & interop. That means the distance between bug and test is basically 2 projects wide. https://github.com/ipfs/go-ipfs/blob/67fdb6efcdd1d4c0c0ee6fef7190b92c13184dbd/.circleci/main.yml#L229
There is a libp2p https://github.com/libp2p/test-plans project,
There is a libp2p https://github.com/libp2p/interop project, which tests between js and go, but it was disabled (not sure why),
There is an ipfs https://github.com/ipfs/interop project, which might be still used.
It’s OK to have some tests needing k8s and that can’t run on local (NAT and firewall probably),
It would be nice to make sure they can run on a dev machine (⚠️ Marteen uses an M1 so that raises the compatibility issue).
What does the story around browser / Chrome / Firefox testing look like in testground?
There are very different browser APIs, and we want to test the interoperability of libp2p running in a firefox browser ↔ libp2p running in a chrome browser ↔ libp2p running in node, go, etc.
Note, from my (laurent) understanding, we rewrote the whole sync service to use WebSockets which should make it usable by a puppeteered browser.
Cross-Version Testing (~ Regression Testing)
One important feature we can’t work on right now, because lack of interop testing, is a feature called “protocol select”, where a multiaddress might contain the encryption protocol too, like /tls . It saves 2 roundtrips, which makes it critical for “time to first-byte” goals the org has.
But dangerous without cross-version testing: we want to ensure full backward compatibility, hard to test without testground.