radicle-link-test: creation of centralised test crate

[FintanH]

Closes #649

radicle-link-test becomes the defacto crate for testing code. The following changes are made:

Moving librad-test to radicle-link-test. Moving librad/tests, git-helpers/test to radicle-link-test/src/integration. Moving all librad, git-ext, and git-helpers unit tests to radicle-link-test/src/unit. Moving all librad property tests to radicle-link-test/src/properties. Moving all (relevant) librad test support code into radicle-link-test/src/librad.

Signed-off-by: Fintan Halpenny fintan.halpenny@gmail.com

[FintanH]

Todo:

• [ ] I've left out daemon so far don't want to create conflicts with the work @kim is doing
• [x] Remove dev-dependencies
• [x] Audit for changes to tests in master

Also holy shit, just noticed this is #666, very ominous...

[kim]

I am wondering if we should go for tests/{unit,integration,properties}, or stick the support code into lib, support, or something.

[FintanH]

I am wondering if we should go for tests/{unit,integration,properties}, or stick the support code into lib, support, or something.

Well so far I've been sticking them in their mirrored hierarchies. So for example, here's the urn support code.

Or are you thinking lib, support for this kind of harness code?

[kim]

Yeah just a moment of being puzzled after an initial ls and wondering if I should move the daemon tests into src/daemon or src/integration/daemon. I think either one of these would work:

src
|-- support
|   |-- <crate1>
|   `-- <crate2>
|-- integration
|-- properties
`-- unit

or

src
|-- <crate1>
|-- <crate2>
`-- test
     |-- integration
     |-- properties
     `-- unit

Maybe the second one is better, because the support code may not be tied to a particular crate in the longer run.

[FintanH]

My preference would be for option 2. Seems clear and also easier to handle the change :smile:

[kim]

Just one more nit: do we want to call the directory radicle-link-test while we omitted radicle(-link)* so far?