Structuring Selenium tests to avoid duplication

Question

I'm refactoring our test suite to take advantage of page object pattern. I'm missing how to structure the actual tests.

Lets say that I want to test StackOverflow posting and deleting. Once scenario may look like this:

Scenario 1: Posting Test

1. Login
2. Create a post
3. Verify that the post is visible

Scenario 2: Removal test

1. Login
2. Create a post
3. Remove the post
4. Verify that the post is gone

My question:

The general guidelines for auto tests seem to be to have as few items asserted as possible. However, it is quite obvious that Scenario 1 and Scenario 2 are nearly identical and violate DRY. On the other hand, if I combine these two it's going to be difficult to understand the failures and perhaps the length with impact readability and ease of maintenance. Given that in real testing, there may be scenarios with dozens of overlapping steps, what is the best way of structuring them?

Edit:

Here's a blog post that describes a remarkably similar scenario and a potential solution. Briefly, the suggested solution is to create PostTest class, and then inherit RemoveTest class from it. This adheres to DRY, but I still have my doubts about this approach. If posting fails, both Posting test and Removal test will fail and produce noisy output (especially if tests are executed in random order). I'm still not sure this is better than a monolithic "Post & Remove" test.

Answer 1

I use the page object pattern myself. It addresses two main things:

1. Defines the finder in one place
2. Names the finder with english-like words

Good things. However this doesn't address the issue of how to combine series of steps that are then used in multiple places.

To do this you can use use functions / procedures / methods in the language you are using. Broadly speaking you have two choices for doing this sort of setup - using the application screens, or using backend calls to create the needed objects.

Answer 2

Like Michael said the Page object pattern makes the finder easier to use. I try to maintain a pattern of having a test only verifying one thing or possibly one screen. In your example I would assume in your first test, you would be testing everything about the post being visible. In your 2nd test, the create a post step is only a setup step so that you have a post to delete and this is what you are doing your verification on. Depending on what makes sense, I would only have an assertion on the post to validate that it successfully posted, not assertions around visibility.

Answer 3

In my experience, as you correctly mentioned, if creation fails, deletion cannot be even tested, so in fact you have just one test with 2 separate test conditions.

So far for every separate scenario I have only one test with multiple test conditions. Test starts with preparing system to certain status, which will be irrelevant for other tests. Then all subtest expect this condition, or success of previous steps. I found that unlike unit tests, integration/system tests are much harder to make independent from each other.

Reusable code goes to pageobject or to helper class, and there is little repetition, so my approach so far works OK for us.