I have some (semi) automated tests for the UI Javascript here. These tests are pretty useful for the most complicated parts and we should aim at introducing some proper testing framework, as well as automating tests execution during the application build cycle.
For the former aim, there are a lot of test libraries and hence we should first evaluate the one we want to use. From what I see, Jest is a popular and feature-rich one, but I'm open to discussion.
After that, we should start from the above-mentioned tests, convert them into the chosen test library and arrange things so that we can run the tests from the command line (presumably, assuming NodeJS is installed and using it) have some report (ideally, on file, but standard output is OK too) and have the corresponding command exiting with a non-zero code in case of failures, so that we have a mean to stop the build when needed.
In detail, this implies test .js files, which Node.js can load, see and execute imports about the test framework, see and exec other imports about the code to be tested and then run the unit tests in the loaded files. Such test files should stay separated from the files that are deployed with the web application (if we want to follow Maven conventions, they would be in client-base/src/test/javascript).
Once we have this, integrating this into the Maven build is quite simple and I can work on that.
Note that, for the moment I'm only considering those cases that can be automated and don't require any browser. Testing UI components is a different and more complicated matter.
Also, if we start doing this in the current Knetminer, it's some useful experience for the new architecture.
This is a smaller sub-task of #733
I have some (semi) automated tests for the UI Javascript here. These tests are pretty useful for the most complicated parts and we should aim at introducing some proper testing framework, as well as automating tests execution during the application build cycle.
For the former aim, there are a lot of test libraries and hence we should first evaluate the one we want to use. From what I see, Jest is a popular and feature-rich one, but I'm open to discussion.
After that, we should start from the above-mentioned tests, convert them into the chosen test library and arrange things so that we can run the tests from the command line (presumably, assuming NodeJS is installed and using it) have some report (ideally, on file, but standard output is OK too) and have the corresponding command exiting with a non-zero code in case of failures, so that we have a mean to stop the build when needed.
In detail, this implies test .js files, which Node.js can load, see and execute imports about the test framework, see and exec other imports about the code to be tested and then run the unit tests in the loaded files. Such test files should stay separated from the files that are deployed with the web application (if we want to follow Maven conventions, they would be in
client-base/src/test/javascript
).Once we have this, integrating this into the Maven build is quite simple and I can work on that.
Note that, for the moment I'm only considering those cases that can be automated and don't require any browser. Testing UI components is a different and more complicated matter.
Also, if we start doing this in the current Knetminer, it's some useful experience for the new architecture.