Test code separation

As someone who spends quite some time writing and checking unit and e2e tests I’ve started noticing a trend I’m somewhat confused by. There have been multiple occasions in which I’ve encountered test logic (repeatable and single use) in either test specifications or page objects. So I decided to share my approach to writing and foremost separating my test code into three categories. Those being: Specifications , Sequences and Page Objects. I’ll describe my views on these categories below.

Specifications

The first category is the one we all use the most. It is the bread and butter of testing and describes our tests. For me this always follows the same general steps.

• The setup where we set required variables and states,

• the execution where we call the functionality we’ll be testing and

• the validation where we check the result and/or side effects.

Sequences

This less seen category is where we describe reusable test code. This code serves to support the setup and/or execution phase of my tests and consists of often parameterized methods. By separating this from my specification it ensures greater maintainability and easier access.

Page Objects (e2e specific)

This category for me falls in the “it’s the glue that binds them together” part of testing. By this I mean that page object should (in my opinion) be written solely for the purpose of connecting test logic to the browser.

In extension to this it would be nice if creators of component libraries could add page objects to their packages to support testing. This would help those users who use your packages. Because that way we don’t have to reinvent the wheel every time.

In order to ensure this separation we could separate our code using the following extensions:

• *.spec.ts

• *.seq.ts

• *.po.ts

So in conclusion; This is my approach to writing unit and e2e tests. It serves me well and I think that it could serve you as well. But as always I welcome an open dialog and look forward to your opinions. Note that the opinions and practices described in this document are meant as food for thought. If you decide that another approach better suits you and/or your organization I’d advise you follow that course of action.