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.