Should a single use case with multiple validations be separated into multiple test cases? For example, let's say the use case is a customer updates their user name. This name change will be visible in the account header, profile details, and messaging center.

Would you have 1 test case with multiple validation steps(header, profile, and message center) or would you have 3 test cases(one for each validation)?

... Why?

  • What about one setup method run once and multiple test cases verifying different things?
    – dzieciou
    Dec 23 '15 at 19:41
  • I think sometimes it is good for testing validation, there are zero chances to miss any validation
    – PRasd
    Dec 28 '15 at 9:35

When possible it is generally a good idea to break out the different assertions into separate cases even though they will repeat the same setup/teardown. The reason is that when one of the assertions fail you want to know that specifically, with text that describes the test and the specific assertion and if bundled together with other assertions, that may not be obvious.

For example, after trying to create a new record incorrectly you want to assert:

  • There is no new record
  • There is a failure message on the screen
  • The failure message is colored red
  • There is not a success message on the screen

If the test failed at assertion 1, should the other assertions be run? Should they all be reported on as failures? If all three assertions fail will it be clear what the underlying problem is?
Having the 4 assertions together makes answering these questions harder.

In the example you reference it might happen that (only) one of the places where the information is shown is changed, so having a separate test that says exactly where each check is will be more informative when it fails.

When you have multiple expectations you should also see if your test framework allows you to share setup between multiple test cases. If it does then these can just be separate test cases that are sharing a common setup in the setup - execute - teardown process for each test.

Some test frameworks will also exit on the first assertion failure so if there are relevant failures for different reasons these will not be identified until the initial failure is fixed.

Some frameworks allow the assertions to be grouped together, sharing setup, with output showing more information on the grouping that is used and the specific assertions that fail.

  • I would add that as it is likely that the sort of changes the OP describes will, in well structured code, be in separate functions/modules/processes possibly even machines then some test frameworks allow unit test cases to be aggregated for integration tests. Dec 31 '15 at 7:24
  • Also, if using tools such as doors, each of the resulting changes would trace to a separate requirement so a single test for each simplifies traceability. Dec 31 '15 at 7:26

Ask yourself what happens is one of three tests fails, in theory the test will be marked as "Not passed". If you extend this approach to the whole test plan it will not be simple to quickly identify failures because you need to read failed cases one by one. Finally, based on my experience I would not collect two or more verifications on a single case.


It depends.

If the number of steps required to verify header/profile etc. are not too many then I should keep it in the same test. Otherwise, I prefer separate test scripts.

And also, I will look at refactoring the tests so that the 'user name change' test becomes part of tests related to header/profile.


For scenario you mentioned, Its better if we prefer 1 test case with multiple validation because there are not too many validation.

If you are expecting more validation for user name changes in future, then you should separate it out in different test cases.

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.