I agree with the other commenters that the Page Object Model is a great way to structure test code for interacting with the page, however, for the tests themselves, I recommend writing tests for functionality instead of page-by-page.
Tests aren't about validating pages, after all. All of your users and most of your staff don't care which page something is on, they care whether it works or not.
There's a bit of nuance. Unit tests will often run against a single component of a page, whereas functional tests run across multiple pages. For a functional test, grouping by functionality reflects how your developers will make changes, and allows for sensible multi-page tests. For instance, imagine you're writing a mortgage application. There are five steps for making a new application:
- Create an account or log in on the homepage
- Provide your ID
- Provide the property details
- Provide your financial details
- Submit the application
Your users will never visit the 'Property Details' page directly. They must take the other steps first.
If you wrote 5 separate page tests, you'd have to make extra, crappy tests for each page to make sure it was receiving and providing the right data. If you add a new page between 4&5, you now need to change the test code for page 4, the new page, and page 5.
If your application is composed of re-usable components, page-based tests make even less sense. Say users can provide financial information without logging in, on order to estimate how much they can borrow. If you're using page-based tests, you have to write and update both tests when that component changes.
If instead you're doing functionality grouped tests, you can instead create a page object for that component and write a unit tests for it. Then, during your functional tests, just pass the page object the relevant data for either page, and assume that