Currently the LiteFarm codebase has some unit tests for the Express API written using the Jest Javascript testing framework. There are individual test files for each of the user flows in the app and the naming convention for these files is <<userflow>>.test.js. Here is an excerpt.
...
Early in each sprint QA writes test plans for all tickets in the sprint, which can be found in the projects confluence page under the Sprints section and linked to individual tickets on jiraJira. These test plans should be used as guidance by developers when writing unit tests for the api and will specify the minimum test requirements for the ticket(can be found in the “Back end” column of the test plan page). Developers are encouraged to exceed this guidance when writing their tests based on their own unique knowledge of their solution. QA will review each PR and approve only Apart from the current reviews of pull requests by members of the engineering team before merging into the integration branch, QA is required to also review each pull request and their approval(or lack there of) will also block merges into integration. QA will approve PR’s when the minimum test plan requirements have been implemented.
Example
LF-2229 includes changes to the API, the test plan for this ticket outlines some API testing requirements, the resulting Jest tests in the code base look to confirm these API testing requirements are met, one of these tests is below:
...
One of the requirements for LF-2229 is that only users with permission to modify the task date are allowed to modify the task date via the API, the test plan looks to test that this requirement is met in step 7 and the Jest test above also partially confirms that this requirement is met by ensuring that a farm owner account i.e. an account with administrative permission is indeed allowed to modify the task date via API and that the date is updated in the database.
The future
It has been agreed that a departure from the current pattern where mock factories are used to setup database state for Jest unit tests in favour of a seed database with pre-made farms, users, crops, etc. that create a few baseline environments for testing would be preferable as this would make the tests much shorter and more readable. But this approach is not without its drawbacks most notable of which is that a significant refactor of the current test suite would be required. Another drawback of this approach is it would also introduce the complexities of keeping the testing files in sync with the seed script.