Home/ Questions/Q 3968548
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-20T03:51:22+00:00

G’day, I’m working with a fairly DB heavy web app and looking at setting

  • 0

G’day,

I’m working with a fairly DB heavy web app and looking at setting up automated testing for it using Selenium. However, as an automated testing newbie, I don’t know where to start.

  • How do you categorize your tests to make sure they’re logically sound as well as complete?
  • How do you deal with the DB when testing? Build a fresh DB before every test and drop the tables after each test? Start with a test-db?

Just looking for some pointers to what best practices are in this regard.

Thanks,

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    In general…

    If your main goal is to test database CRUD operations I would go at least ‘one level down’ and write some kind of integration tests that do not use the GUI for testing. The tests become a lot more focused on the actual CRUD operations if you take the GUI out.

    How to deal with the database…

    No matter whether you go with Selenium or integration tests it is a good idea that the tests do not depend on each other. This means setting up the database before each test and/or tearing them down to a clean/known state after the test. Maintaining tests that are written this way is a lot easier. For example, you can run a single test by itself.

    For both of our integration and acceptance tests we use dbunit to achieve this. Easily setting up and tearing down DBs is not a new thing, there should be something available for your technology stack as well. (You did not mention the technologies you are using)

    How to categorize the tests…

    For CRUD operations I would make sure I test one thing and one thing only. For example, I have an Employee table. You can have a test suite that tests everything that has to do with an Employee, but a single tests should only test one thing. ‘Save Employee successfully‘ should be a different test case from ‘Attempt to save an Employee that already exists‘ or ‘Delete Employee‘.

    EDIT: (Answer to the comment)

    We basically kill the database and build it from scratch at the beginning of the testing. (Not sure how crucial this part is, but this makes sure that our db is consistent with what the code expects. We are using hibernate…)

    Then for each test we have a different datasets to insert. So let’s say again that we are testing Employee. If I want to test deleting an Employee I would insert a dataset that contained the smallest amount of information in the database to make this happen. Smaller datasets are easier to maintain. If you use the same dataset for all of your tests it will become very hard to change the code and change or add new tests.

    We do use the same dataset for things that seem to require the same information. For example, you want to test ‘Attempt to save Employee to database‘ and ‘Delete Employee‘. You might reuse one dataset for this.

    I was wondering if building and
    tearing down the DB for each test
    would be expensive time and computing
    wise?

    I would not worry too much about this. Yes, it might add, let’s say, 3-4 seconds to every test, but in the big picture, is this really important? It is more important that you have tests that aim for maintenance because your time as a developer is a lot more valuable then these tests taking 5 minutes to run instead of 3 minutes.

    • 0