On 01/07/2018 05:57 PM, ng0 wrote:
>> Well, it may not be technically unit-testing, but the common style we
>> follow in this case is to create a test (that is run as part of 'make
>> check') which simply launches the peer (via ARM), runs the tests, and
>> then stops the peer.  For multi-peer tests, we have the testbed API (C)
>> or the gnunet-testbed-profiler (shell scripts, etc).
>>
>> But aside from this slightly more evolved setup/teardown, it is best
>> practice to write such tests to try to achieve code coverage, just like
>> you might do with unit tests.
>>
> Wouldn't in the case of guile tests that are written with some
> guile specific test framework be better?

Well, regardless of what *testing* framework you use, you do need to
launch GNUnet peers, which is not a trivial process. So your testing
framework should integrate with GNUnet-testbed (be it by exec'ing
gnunet-testbed-profiler or by linking against libgnunettestbed) to
launch the peers.

So yes, maybe you don't launch the tests as part of 'make check' because
you have a different build system, but the rest of what I wrote should
still apply.

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
GNUnet-developers mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnunet-developers

Reply via email to