3

Looking for some best practice here:

I'm looking to future proof the selenium tests that I'm building. They'll involve shared elements (products/locations/users), and it seems like a bad pattern to be building unique, test specific data for each test in isolation.

So how do I avoid my setup/teardown potentially wrecking other tests?

2

Bootstrap a clean environment for each test to test in isolation. This might look like a lot of overhead, but is very needed if you want to parallel run your tests and not get flickering and possible untrusted tests.

Personally I create a session GUID and then generate test data and store in it in a database with the GUID. Boot an environment and let it point to the dataset. Automating this should already be part of the automated build-pipeline, if not this is a good reason to start working on it :)

Also read my answers to https://sqa.stackexchange.com/a/12225/3201 and https://sqa.stackexchange.com/a/13660/3201 which are about managing testdata and environments.

0

If database creation is slow compared to TRUNCATE, create a pool of databases

Then:

  • when each test finishes, it can truncate the DB, and marks that DB as unused in a synchronized in-memory set data structure
  • if a test starts and there is no free DB, it just creates the DB and adds it to the pool

Then you end up with databases named like:

  • testdb_0
  • testdb_1
  • testdb_2

Consider using in-memory database

It might be worth checking if using e.g. SQLite in-memory can considerably speed up the DB creation process. If it does, you can just use one DB per test as mentioned at https://sqa.stackexchange.com/a/16855/49066

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.