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?
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:
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.
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.
