Server Testing

This page aims to outline the testing strategies and general philosophy of the server side application. The testing is split up into two types, API integration and unit testing, each discussed separately but share some common configurations. For running tests, see Running Tests.

• Author: Rachael Daly <rld5989@rit.edu>
• Author: Alex Wilkes <adw4236@rit.edu>

API Integration Testing

The integration tests exist under the /server/test/routestest folder. All defined routes should have at least one test associated with them proving their success, but many will have several proving their failure with bad input.

These tests strictly make API calls and don't mock any part of the server so that they can fully test the integration of all aspects of the server. The database used is a clean in-memory mongoDB so that the tests can be ran anywhere without any need of a specific database and data-set.

In order to reduce the amount of setup required for each integration test and therefor reduce the runtime, the tests must be ran in order. Each test expects the proceeding test to have executed successfully and that the state of the application and database will be as such.

The metric we aim to meet for test coverage is 95% statement coverage and that should be reflected with every merge to master at the end of a PR.

Model Tier Unit Testing

Model Tier Unit testing takes a much more standard approach to testing. Every test should be able to be ran independently and all setup and teardown should be done for each test. This means that the database must be cleared after each test.

The standard three sections of the test apply with the first portion of the test dedicated to setup of the test, the middle portion to execution of the test and the last to validation of the results. These sections should be clearly visible with whitespace or even comments if needed.

When initially writing unit tests, it is important to think of as many possible edge cases to the input (which includes both parameters and application state). More importantly however is that whenever a bug is found in the model tier, a new unit test should be written (or a previous one modified) to address such a bug.

At this moment, there has not been any usage of a mocking framework, but it may be advisable to do so in the future as domain logic becomes more complex.