light-client icon indicating copy to clipboard operation
light-client copied to clipboard

Write tests for the API / CLI

Open christianbrb opened this issue 4 years ago • 4 comments

Description

Currently, it is getting difficult to continue developing the new API as there are no tests. We need to write tests for the current functionality and configure GitHub and CodeCov to check for a threshold.

@weilbith Anything to add?

Acceptance criteria

Why do this?

We should have tests in place to ensure the CLI/API works as intended.

christianbrb avatar Jun 16 '20 13:06 christianbrb

No not really. I just want to say that these tests should not test the protocol functionality of the SDK, but actually only this application interface. But sure there will be an intersection.

The big question (for me) is how we would design these tests. For development it would be great to have some kind of unit test properties. So they allow you to follow a test driven development approach. On the other side this is pretty much end-to-end testing, since the API is at its best be a thin wrapper only. Mocking the SDK would solve that, but may be too much work or simply not accurate enough. Especially when implementing new endpoints. This is a bit strange because the SDK is concurrent touched to support the CLI as good as it can. So back again: this are at least integration tests, more likely end-to-end tests.

After all I would like to be sure that I did not destroy anything when I open a PR. So in case there is only a complex e2e solution, I would argue to let it do the CI setup.

weilbith avatar Jun 16 '20 14:06 weilbith

If we don't go with mocking/stubbing then the other approach is essentially e2e. We could use the infrastructure (docker image) that already exists for e2e if we need, but they will be slower compared to unit tests since they require starting the docker image to run them.

kelsos avatar Jun 17 '20 11:06 kelsos

@andrevmatos Could you update this issue with some more details on which tests make sense writing? I guess adding some e2e tests should be enough?

taleldayekh avatar Jul 12 '22 09:07 taleldayekh

e2e is an option, but they're slow and cumbersome to run (requires docker setup, etc). Since the CLI is mostly stateless and rely on the Raiden SDK instance for everything, unit-testing each API with a mocked Raiden will cover most of our code. This should be the fastest.

andrevmatos avatar Jul 14 '22 16:07 andrevmatos