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](https://github.com/FiTRSkills/ForkInTheCode/wiki/Development-Environment#running-tests).

- **Author**: Rachael Daly <[rld5989@rit.edu](mailto:rld5989@rit.edu)>
- **Author**: Alex Wilkes <[adw4236@rit.edu](mailto: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.
