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 workflows in the app and the naming convention for these files is <<workflow>>.test.js, also under the tests folder is a mock.factories.js file which contains some mock data factories that are useful for testing the code (you can read more about this in the factories.README.md under the same directory).
If you open one of the test files you will notice they take the following structure:
import {describe, expect, test} from '@jest/globals';
import {sum} from './sum';
describe('sum module', () => {
beforeAll(() => {
//some action that must be performed before each test
});
test('adds 1 + 2 to equal 3', () => {
expect(sum(1, 2)).toBe(3);
});
});
The tests make use of ChaiHttp to make requests to the endpoints under test, which must first be declared as functions as follows:
function patchManagementPlanRequest(
data,
{ user_id = owner.user_id, farm_id = farm.farm_id },
callback,
) {
const { management_plan_id } = data;
chai
.request(server)
.patch(`/management_plan/${management_plan_id}`)
.set('farm_id', farm_id)
.set('user_id', user_id)
.send(data)
.end(callback);
}
The majority of tests then make use of the above functions to call the api with valid/invalid inputs and make chai asserts to the responses as below. In cases where more complex data is required as inputs and the test database needs to be in a particular state, mock factories and faker are used.
test('should return 403 when unauthorized user tries to edit managementPlan', async (done) => {
const reqBody = getFakeManagementPlan();
patchManagementPlanRequest(reqBody, { user_id: unAuthorizedUser.user_id }, (err, res) => {
expect(res.status).toBe(403);
done();
});
});
Once a test is written, you can run the entire test suite as specified in the README file in the LITEFARM repository. You can also run specific test files using the command:
npm test -- <test_file>
Peer review process
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 jira. 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. 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 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:
function patchTaskDateRequest({ user_id, farm_id }, data, task_id, callback) {
chai
.request(server)
.patch(`/task/patch_due_date/${task_id}`)
.set('user_id', user_id)
.set('farm_id', farm_id)
.send(data)
.end(callback);
}
test('Farm owner must be able to patch task due date to today', async (done) => {
const today = new Date();
const due_date = today.toISOString().split('T')[0];
const patchTaskDateBody = { due_date };
const [{ user_id, farm_id }] = await mocks.userFarmFactory({}, fakeUserFarm(1));
const [{ task_id }] = await mocks.taskFactory({ promisedUser: [{ user_id }] });
const [{ location_id }] = await mocks.locationFactory({ promisedFarm: [{ farm_id }] });
await mocks.location_tasksFactory({
promisedTask: [{ task_id }],
promisedField: [{ location_id }],
});
patchTaskDateRequest({ user_id, farm_id }, patchTaskDateBody, task_id, async (err, res) => {
expect(res.status).toBe(200);
const updated_task = await getTask(task_id);
expect(toLocal8601Extended(updated_task.due_date)).toBe(due_date);
done();
});
});
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.