-
Notifications
You must be signed in to change notification settings - Fork 0
Home
This is a sample code targeted to use the "TestContainers package" for integration tests. you can find more complex examples by checking the official package's GitHub repository, here.
In this project, I created a sample API to save data in an SQL server by EF core7, third-party API, etc. Then I started to develop some tests for these APIs.
TestContainers package helps you to run your project and its dependencies with docker technology and request them independently or with a shared context. I configure this project to run each test independently.
In the test project, there are four folders:
- Builders
- Fixtures
- Setup
- Meeting
All classes are responsible for creating data directly in the database and should locate in this folder.
In this folder, you could add fixture classes per technology or third-party services which are used in your application.
Please inherit your fixture from BaseDatabaseFixture class, If you need to create a "fixture" for technologies - like EfContainerFixture class. On the other hand, if you create a fixture to use a "third-party service," you do not need the inheritance, like ThirdPArtyContainerFixture class. There are several fixtures in the folder; you can use them as a sample code.
Understanding this folder is vital to learning about the code, so please read this part more carefully.
Each API needs different dependencies, and loading all dependencies for each test could lead us to tolerate unnecessary costs, so we should load dependencies per test class to save resources. Thus I decided to create various fake API builders for different tests.
In the first step, we should build a Fake API builder. This class is responsible for configuring the application and dependencies that we wish to run for test -by using the fixture. All these builders should inherit the BaseFakeApi class -like MinimalFakeApiBuilder or MaximalFakeApiBuilder.
In the second step, we should add a type to the FakeApiType enum and use them in FakeApiFactory class. As you can see, the "class is a simple factory to return chosen fake API; I have added two types per my two fake-builders.
In continuation, you have to use the fake API builder in test classes.
To summarize, there are tests here. I have created test classes per API service; all of them are inherited from BaseIntegrationTest. There is an InitAsync that you can override in your test class to config much more things in your test. For example, in the "GetMeetingDetailsTests class," I needed to config the application with the maximal API factory. Besides, I had to use MeetingBuilder for data preparation. Thus I overrode the InitAsync and used it in that way.