We reused a registration table from Chapter 5, Writing simple test scripts, to create a new player for tests in this chapter. Although every programmer knows that it is nice to reuse existing code, watch out for this kind of reuse, especially when you copy several tables from another page just to set the stage for a new test.
As the project advances, you often add new tests as extensions of previous tests, continuing a bigger story or checking an alternative scenario. In these cases, you might just copy parts of existing pages or even complete pages into the new setup. Chances are that these new tests don't need that much detail. Having five large tables up front that check irrelevant conditions, just to prepare the stage for another test, only makes the pages harder to read and maintain.
Treat your test pages like code. When you see duplication, refactor it. Having copies of groups of tables in various pages, or used together to set up tests, is a good signal that they should be consolidated into a smaller utility table. It might also be a signal that you are not testing the business rules directly.
All the user details in this chapter are unimportant. The full registration table is relevant only for the original test, where we had to verify that correct data is stored in the system. All we want to do in this case is to create a new user called John. We can write a new fixture that quickly creates a new user and use this instead of the big table in tests from this chapter. Because we are not interested in user details, we can just randomly create user properties.
