CODEWITHSUNDEEP
javaseleniumjunitautomated-tests
kiedysktos
kiedysktos

Reputation: 4100

How to design / organize tests related to Create/Read/Update/Delete operations in CMS? (Selenium)

we have CMS web app where we do following actions:

- add new / modify customer profile (company)
- add new / modify users of company
- add new / modify content by users
- etc...

For now we developed some amount of tests using Selenium + JUnit, in following fashion:

addNewCompanyTest()
updateCompanyTest()
deleteCompanyTest()

The thing the best practice would be to perform clean up after addNewCompanyTest() (deleting newly created company) which would in fact be performing same steps as in deleteCompanyTest(). I invoke the same method deleteCompany(Company c) in both tests.

And deleteCompanyTest() is in fact creating a new company, so it looks like addNewCompanyTest() is redundant, because it has to pass if the other works.

I have two ideas how this can be managed:

1) Force the tests to be executed in given order

I can use JUnit feature of executing tests in alphabetical order (which would require tests renaming), or switch to TestNG because it supports test order. But is this a good practice, since people even go opposite way, forcing random test order?

2) Create one test companyCRUDTest()

In this test I would create a new company, then update it, and delete it.

What it the best approach here?

If 2), then do you remove smaller tests like addNewCompanyTest()? Maybe it's better approach to just focus on the higher level tests like addAndDeleteContentAsCompanyUserTest() which would create Company, create User, log in as User and create a new Content, and then delete it, instead of maintaining low level ones?

Upvotes: 1

Views: 467

Answers (1)

ᴇʟᴇvᴀтᴇ
ᴇʟᴇvᴀтᴇ

Reputation: 12751

In my view you shouldn't optimize out repetition in the tests simply because you happen to know how they are implemented.

You should explicitly test each required behavior and combinations of behavior. Each test should be runnable on its own and explicitly set-up its desired state and tear down (reset to a known state) whatever changes it made after it has run.

The way I would implement this is to create a little internal testing "API" for adding, deleting and updating companies. You might also write a reset() method that deletes all companies. You can then call these API methods from the test methods without creating lots of duplication. This API will also let you add more complex tests, such as adding several companies and then deleting some of them, adding the same company twice etc.

An alternative to resetting afterwards is to reset before each test. You could put the reset() either into the @Before method or an @After method. The advantage of doing the reset before the test method is that if a test fails, you will be able to see the erroneous state. The advantage of doing reset afterwards is that you could optimize it so that it only deletes what it created.

Upvotes: 1

Related Questions