Use code reviews to have discussions about your test automation code

Published on July 9, 2024

Learning from discussions originating from code reviews is helping me create a pack of automated tests using TypeScript and Playwright. 

I have been developing a pack of Playwright tests with a Page Object Model. A simplified example of a page in the Page Object Model looked something like this:

A simplified example of a test:

When I created the pack I was pleased because I felt tests were easy to maintain and read. However, from a discussion following a code review, I learned how to write the test with fewer lines of code, making the tests easier to read. The functions should create page objects used in the test. This change would have two improvements:

  1. Each test would contain fewer lines of code because fewer pages need to be imported and a constant does not need to be created at the start of the test.
  2. When a test makes a search it returns a searchResultsPage, this means that the test reads more like a story.

The function search() now returns a searchResultsPage object. The simplified example of the Page Object Model now looks like this:

In the example test, the SearchResults Page is no longer imported, a searchResultsPage constant is no longer created at the start of the test and a searchResultsPage object is created when a call is made to search(). The simplified example of a test now looks like this:

The test pack I am developing has more than two Page Objects so this pattern reduces the number of lines in a test by an even greater amount than in the example. The tests are also now easier to read.

The advice from the code review and the following discussion helped me develop better tests by giving me a better pattern for automating tests. The important learning for me is not the better the code pattern but how code reviews can lead to discussions that help me improve my test automation code. 

Further reading about code reviews:

Implementing Lean Software Development: From Concept to Cash by Mary and Tom Poppendieck (2006, chapter 8 Quality)