What is the best practice to use sequential test-cases?

Question

I know that, in test automation, we have to avoid sequential test-cases. So, the order of running the test-cases are not important.

I believe in some cases the sequential test-case is unavoidable:

1. Consider a scenario which a user needs to take some previous steps in order to complete a final goal. For example, a user needs to be logged in, so that they can purchase.

   Given User is logged in
   When  User adds an item into their basket
   And   User completes their purchase
   Then  They receive an Email
   

   So, in above scenario, each part (Given, When, And, or Then) are separate test-cases. But still the order of test-case is crucial.

2. Also, Junit team provides a method called @FixMethodOrder(MethodSorters.NAME_ASCENDING) for such usage, but I am not sure when we are allowed to use this.

How do you write independent test-cases in end-to-end testing?

Answer 1

Test cases don't need to complete an entire workflow at one time. This often makes them flakier and may limit the granular visibility of what works and what doesn't when they fail. The first thing that comes to mind is you should have available data and tools in your testing environment that allows you to break up that workflow into smaller pieces. As one possible example

GUI level tests:

1. A user logs in and adds an item to the cart, assert against the cart.
2. A different user logs in with an item already in the cart (thanks to your data setup), completes the purchase, assert against the completion view.

Service level tests

1. Simulate the service/API call to send an email. Use something like a mail catcher utility and assert against the receipt/correctness of the email.

Answer 2

So, in above scenario, each part (Given, When, And, or Then) are seperate testcases. But still the order of testcase is crucial.

1. They should not be separate tests. This might be a constraint you or someone else has put into the system (hopefully not a technical constraint) but you should question the value. How often do your users log-in and then not do anything? Probably never. Why would you want this to be a singular test?

2. You should definitely separate those actions into their own re-usable methods such that each test can use the same code as necessary. However as it's already been said, each test in and of itself should be atomic (capable of running on it's own / not depending on another).

3. If some tests have unique conditions and need some data available, as Cherree noted, you should be able to setup and teardown those conditions up within the test itself.

Answer 3

When pre-conditions are required you should create these as part of the setup.
The best practice for sequential test cases is to avoid them and use a different setup approach instead.

For example, for "Given I am a logged in user visiting screen x" we may need to create a user, set the password, verify account, perform the login, navigate to the screen. All of that needs to be in the setup for the "Given".

As others have noted, it's best to make these various actions (e.g. 'login') reusable methods because desired states like "logged in" are likely to be shared amongst a great number of cases.

A very common approach used by many organizations is to take an existing user, use an existing account, use existing orders, etc. This is brittle. It works for a few days/weeks/months and then breaks because the account changes. or is locked out. Or the order is archived. Or paid off. etc. Basically what you encounter is that state changes. You need to control state to avoid this. In order to control state you need to create ALL the test data - users, accounts, orders, everything. This will also lead to some interesting decisions, e.g. "but surely we must have all 65000 us state codes in our database", with the answer "we don't distinuigh any business based on zip code so one valid 5 digit zip code is all we need (along perhaps with one invalid, shorter/longer, alpha digits etc for testing).

Companies with large databases and existing systems may consider this extreme and impractical. It is not easy but many other large (often newer) companies have figured out the importance and need to do this despite the initial challenges and hard work. Often, for large companies code to instantiate objects and set state already exists in the form of application APIs through SOAP, REST, etc. The challenge then is to leverage this existing application infrastructure for the purpose of testing and automation.