A page that shows saved state depends on data the test has to set up first. The rule is: the test creates its own state, asserts on it, and cleans it. A test that reads whatever state exists is a test that changes with the site.
About 1 min of reading
Test one piece of saved state
Create the state
Before you run it, say out loud what it will print. Then open the answer.
Assert the created item shows
Before you run it, say out loud what it will print. Then open the answer.
Clean it
Before you run it, say out loud what it will print. Then open the answer.
Run the test twice
Before you run it, say out loud what it will print. Then open the answer.
Repeatability. A test that leaves state behind fails the next run, and a suite that fails on its own leftovers is not a suite.
If setting up state costs a slow job, split the assertion into a state test and a render test, and assert the render on a fixture.
Add one item, assert the page shows one item, remove it. The three steps leave the site as it started, so the test can run twice.
Assert the item you added is present, not that the list has a fixed length. Another user's data changes the total and the test fails on someone else's work.
Use a test account made by the test. A shared account makes two runs of the suite interfere with each other.
Each one is defined here on this site. Open the entry for the full definition and the other words it points at.