passing a common test suite (which we'll extract from go-ipfs)

[mvanveen]

@jbenet calls this out in #1. Judging by #8 people seem to agree with the principle that developing against a testable spec is a priority.

I'm curious how we're going to go about accomplishing and structuring this goal. I realize the actual written spec is still in progress (I myself am still coming up to speed on the protocol specifics).

I'd like to use this issue to center discussion on planning for how we're going to tackle this issue.

[mvanveen]

I think as @jbenet highlights we can "extract" working definitions from the existing golang reference source code and start putting together a test suite from that material. So there's some ways we can get started even while the spec is being finalized.

Another interesting approach might be to design a functional test harness which can use python-ipfs-api and py-ipfs interchangeably. The idea here is that we could leverage the golang implementation via a pythonic test suite initially and get started on designing a set of test cases immediately while py-ipfs is still being built.

[bmcorser]

So, the Sharness suite is here ... coverage table is here. Those will be really useful when our implementation here gets underway. @jbenet mentioned that the above will be broken out into a repo of its own soon. This may coincide with the suite becoming useful to this project; if not, we can subtree from there and start using it anyway :)