-
Answered: Prevent duplicate entries in test runs
In order to test some functionalities of a grid we have on our website I am currently creating new entries for each test run that I can then alter and act on in my test suites.
After the tests have run an afterAll()-Function deletes these entries.
Now if for some reason the test crashes and the afterAll()-Function does not get executed properly these entries still remain and will raise a conflict in the next test iteration as they'd be duplicates.
Is there a way to prevent this?
My idea was to check the grid's entries before creating a new entry and if an entry with the same identifying stringalready exists in the grid concatenate a '1' to the end of the new identifying string.
If so, how would this be implemented?
-
Best Answer Posted by
daniel.gallo
How about doing a "beforeAll" that deletes any test data in the database at the start of a test run - either calling out directly to the database via a SQL query or executing a procedure in the database to remove test data, or looping through a grid and clicking "delete" icons for records?
-
How about doing a "beforeAll" that deletes any test data in the database at the start of a test run - either calling out directly to the database via a SQL query or executing a procedure in the database to remove test data, or looping through a grid and clicking "delete" icons for records?
-
That's a great idea, I'll definitely try using direct DB queries.
But it would still be more elegant to remove these entries after a test has run, right?
Is there sth. comparable to a finally()-Method (as in JAVA's try-catch-finally statements) in order to make sure code gets executed?
AfterAll() does seem a bit unreliable from what I've experienced.
-
In one of my previous apps, I've cleared out the test data before the tests run by using a "beforeAll", just in case the tests fail prematurely or encounter an unhandled exception which prevents the tidying up from being completed at the end of the test run.
In a full test environment where the tests are automated, this type of cleanup could probably be best handled as an extra build step in your CI environment (Jenkins / TeamCity), outside of the Sencha Test process - either restore a baseline copy of the database before / after "stc run" is executed, or have a procedure in the database that's executed to remove data that belongs to a test user account.
Tags for this Thread
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules