We have a Spring Boot application, which uses RDS service for storing data (PostgreSQL, VPC + private subnet particularly) and Cognito for the user authentication. All this jazz is deployed in automation (Jenkins + CloudFormation). Now, we have a few end2end tests, checking that app is alive. The question is, should we go further and try to test the functionality, requiring some test user to be authorized. Personally, I would prefer it to be tested, but there are some obstacles which I don't know how to approach.
Normally within e2e testing, you would like to have a clear DB at the beginning of each test (or a bunch of tests) with similar preconditions. For that, you apply a snapshot with the desired state of DB or simply drop all tables.
Is it possible to do it on the AWS (DB is not publicly accessible)? Am I supposed to use RestoreDBInstanceFromDBSnapshot command for that or there are other ways to do this? How to prevent case when DB schema has changed, but we still restore from the old snapshot?
We can have special endpoints just for the test environment, but it is kind of unfavored because it messes up the code
Not sure how you get your release out like application and database patch at the same time or different releases depending upon if there is a database change. As a lot will depend on this
I prefer the e2e test cleanup the database data after them. What i mean is this test insert data into database and may be in the teardown method or may be a totally new test deletes all the record created by/for testing and in between this 2 process you can carryout your normal tests.
Here i am assuming that you are following the test pyramid with e2e test being the slowest and less in quantity compared to system integration and unit test.
This might be a bit tricky depending on the scenarios you want to test and when running simultaneous/concurrent tests, there is a workaround here to use different data for each test.
I would prefer you apply a snapshot with the desired state(here i mean not with the pre-populated testing data, but just the table schema with required master data).
If there is a schema change you would still take a backup of the existing, apply the new script changes for schema and then run the test.