The thing about writing test, either unit test or functional UI test, is repeatability. Back then I had this problem too, to which I had worked on getting a script to drop the database, and recreate it back again, repopulating it with consistent test data.
Then, docker-compose came along. It is so easy right now to just have an environment up and running consistently. And once the test is done, the whole container set of the docker-compose can be easily removed, and created again on a whim.
For most database containers, you can just attach your sql files into the volumes that the database engine reads, and you will have consistent test sets overtime.
This will solve :-
1. Running test again and again, will make certain elements go of page because of pagination.
2. Creating new data with the same data to ensure uniqueness and testing it, can be done, because it will be a clean slate everytime.
3. Previous data causing inconsistent state with the current test
This does not solve every issue with functional UI testing, but in my experience, having consistent data every time is huge! No more second guessing when you write the logic in your test in fear of having existing data or any manual testing data breaking your test.
The thing about writing test, either unit test or functional UI test, is repeatability. Back then I had this problem too, to which I had worked on getting a script to drop the database, and recreate it back again, repopulating it with consistent test data.
Then, docker-compose came along. It is so easy right now to just have an environment up and running consistently. And once the test is done, the whole container set of the docker-compose can be easily removed, and created again on a whim.
For most database containers, you can just attach your sql files into the volumes that the database engine reads, and you will have consistent test sets overtime.
This will solve :-
1. Running test again and again, will make certain elements go of page because of pagination. 2. Creating new data with the same data to ensure uniqueness and testing it, can be done, because it will be a clean slate everytime. 3. Previous data causing inconsistent state with the current test
This does not solve every issue with functional UI testing, but in my experience, having consistent data every time is huge! No more second guessing when you write the logic in your test in fear of having existing data or any manual testing data breaking your test.