Testing

All new code should have good test coverage and feature integration and unit tests.

The main tools used for testing in this repository are XUnit, Moq, and FluentAssertions.

Unit tests

Updated guidance: there is no need for unit tests except:

• for rather complicated or obscure business logic e.g. WeaponBodyResolvers which calculate weapon ability levels from unbinds
• if you really want to write them

In general I have found that we get far more value from integration tests that feature actual requests connecting to a database and that these tests are easier to maintain.

Unit tests should be designed to test the logic of individual components in use while mocking out external dependencies. The one exception is repository tests which must be tested in tandem with an in-memory database to do anything meaningful. For a recent example, see https://github.com/SapiensAnatis/Dawnshard/blob/develop/DragaliaAPI.Test/Unit/Services/WeaponServiceTest.cs. Notice how there are a variety of cases and the mocks are controlled to create the test case.

Integration tests

Integration tests are performed by use of the CustomWebApplicationFactory and simulate an actual request coming into the server. They use an in-memory SQLite database which is hopefully a bit closer to the real deal. See https://github.com/SapiensAnatis/Dawnshard/blob/develop/DragaliaAPI.Test/Integration/Dragalia/UpdateNamechangeTest.cs for a straightforward example. PostMsgpack is an extension on the HttpClient, defined in TestUtils.cs which handles some of the boilerplate of serializing the passed in object to msgpack and reading out the response data from the game's response structure.

You are able to manipulate the test conditions by using some methods on the TestFixture to add and remove items from the database.