-
Notifications
You must be signed in to change notification settings - Fork 6
Testing
Junit with Mockito (TBD)
For our end to end service tests we will be utilizing Testcontainers with JUnit 5.
To start writing new end to end service tests you will need to have your test class extend TestContainersSuite.
This abstract class will handle setting up the postgreSQL container which your tests will be using for checkinsdb. This class will zero out the database before each test case, ensuring that your tests will be deterministic and won't affect each other. Lastly it implements the RepositoryFixture, an interface that will contain a way for each of your tests to easily access the database crud repositories without needing to inject them in to your test cases.
Regarding the RepositoryFixture, there are other interfaces that implement the Repository fixture that you may want to implement with your test class which extends TestContainersSuite. These interfaces such as MemberProfileFixture are written to perform common database inserts/queries that one will need throughout their tests. As an example we have the MemberProfileFixture which allows for such things as the quick insert of a new MemberProfile, as many of our service entities require a valid MemberProfile UUID. By calling this one method it will create a default MemberProfile for you and return the entity, which you can then grab the UUID from and use in the creation of the entity you wish to test which has a MemberProfile UUID as a requirement. If you think you are going to use a certain query/insert more than once, or that it may have uses in future test cases please add them to a fixture for reuse.
As we are using a real database stood up for these tests, we will not be utilizing Mockito which are used in the unit tests. That means you will have to insert in to the database all the required entities that will make your test case either work or fail as expected. Similar to how we wrote the Mockito when(x).thenReturn(y), using that same thought pattern now we need to have the database match via the appropriate inserts. Again to make this point clear, each @Test will start with a fresh database with only what is available via the Flyway migrations, so you may have to create a new MemberProfile for many of your tests as an example. For reference take a look at RoleControllerTest.
(TBD)
Cypress framework is a JavaScript-based end-to-end testing framework built on top of Mocha. The core benefits of Cypress include taking snapshots as the tests run and automatically reloading them whenever changes are made to the tests. The Cypress testing container is located in the Web-ui folder of the Check-ins application.
To write your Cypress test, you should start by creating a [Insert name].spec.js file. Your test should cover three phases: set up the application state, take an action, and make an assertion about the resulting application stats (utilize this website if you are writing your first Cypress test.) Lastly, to run the tests, you can use npx Cypress run in your terminal to see the result of the tests or npx Cypress open to open the Cypress app on a browser and see the tests run in real time.