Angular end-to-end testing

Angular end-to-end testing tips (Part 1)

We all love to write end-to-end specs, don’t we?
The reason is that these scenarios act as watch dogs, making refactoring safer and sometimes being the one and only feature documentation existing in the codebase.

The only downside is that sometimes it takes ages to have a proper data setup, resolve CSS classes dependencies and constant CSS/HTML changes. Readability and maintainability are not always perfect too.
Well, we have a few simple techniques that can help you overcome most of the issues described above.
Written for end-to-end Protractor specs, they can be easily used with a testing framework you prefer.

Let’s check a simple example of markup

with related specs

and try to improve them.

Separate test specific attributes

If you have engineers working separately with CSS/HTML and Angular/JS components then you have probably faced an issue that markup changes are not safe in terms of spec dependencies.

Front-end engineer can accidentally break specs by just changing the utility-class name or applying different class according to CSS changes.
Although this issue can be avoided by checking end-to-end specs selectors whenever a markup change is applied, that’s not very convenient.
An alternative solution would be having proper stable semantic classes on every tested element, but that’s just too ideal ;)

The other option is to have a special attribute that is used ONLY by testing framework:

It looks like we are having obsolete attributes all around our markup. Although using this technique we have obtained a number of benefits:

  • Every tested element has a separate meaningful name
  • Markup changes are much easier and safer
  • Specs do not dependent on CSS changes

Page/Component objects

When writing end-to-end tests, a common pattern is to use page objects. It makes easier to maintain and reuse spec examples.
Let’s define simple page objects for our specs:

Test examples will now look like this:

Much cleaner, no CSS selectors in examples but can we improve this even more?
With a common test-specific attribute on every testable element and TypeScript decorators page objects can look a bit fancier:

with decorator defined as:

Now we have reusable spec examples that are not dependent on CSS changes and a nice DSL to define Page/Component classes.
Stay tuned for more tips and tweaks to make your end-to-end testing even better …