Unit and Integration test distinction

[manthanhd]

Hey I'm looking to contribute to the project. Went through and downloaded the source code and ran some tests. I noticed it took some time with a couple failures.

Is there a testing roadmap? I think the tests that are there under the tests folder are integration tests because they are testing the real objects. We should be able to gain confidence faster in the features by some unit tests. I'm happy to undertake this work but wanted to know what the community thinks about this.

So the approach I'm thinking is this. Move all tests that are under ethereumj-core/src/test folder to a new module called ethereumj-core-integration under the same structure. This new module will sit side-by-side the ethereumj-core module. The now vacant folder ethereumj-core/src/test will have place to hold unit tests.

When we do a full build, all the tests will run.

Thoughts?

[mkalinin]

Hey! Thanks for reaching us out with an intention to contribute in tests. This is much appreciated on our side! We don't have a testing roadmap, but there are some testing activities that we have on our plans. One of them is to increase test coverage of the codebase. I would agree on moving jsontestsuit and tck packages to a separate module, cause these stuff is running against test cases from ethereum/tests repository and takes a while, it maybe make sense to move longrun to its own package too. Otherwise, I don't see benefits from having integration and unit tests in a different modules. Regarding modularity. We really tired of our monolithic architecture and eager to break codebase in a set of modules, that is a big task and we have not enough capacity for it at the moment. But when it happens each module will have it's own small set of tests - it makes more sense to me than break tests into unit and integration parties.