AMA: testing business logic in the UI

Stan asks…

With the shift in technology like angularjs, there is a tendency to push the business logic to the UI layer. how is this affecting the testing pyramid?

My response…

It’s funny how technology goes around in Circles. One of the first applications I ever worked on, back in 2003, was a rich desktop application (written in the .NET framework) with a lot of UI layer logic, which was replacing an internal web application that had server side logic.

It seems the client side/server side logic keeps moving back and forth, however, the good thing about technologies like AngularJS and ReactJS is they allow developers to write unit and component tests of the UI components, so I think that’s the best approach: lots of unit/component tests of the UI (with as many dependencies mocked as possible – shallow rendering if possible), less or no integration tests, and a handful of full stack end-to-end automated acceptance tests that run in a browser.

Any client side logic, persistence, state and database stuff is interacted with via an API, and this can be tested through its own unit tests (and possibly few API integration tests – but this also can be covered by your UI end-to-end automated tests).

So, my ideal present day automated testing pyramid looks something like this:

test pyramid watirmelon(2)

 Unit tests for client side logic, unit tests for anything done server side, and full stack automated e2e tests that ensure that at all times our key user flows are working as expected.

Author: Alister Scott

Alister is an Excellence Wrangler for Automattic.

2 thoughts on “AMA: testing business logic in the UI”

  1. You are calling it the “testing pyramid”, but you are only talking about automation – Shouldn’t you be calling this the “automation pyramid” as you don’t seem to be mentioning about sapient, investigative testing at all…?

    Apart from that, this is an interesting post.
    Another question I have relates to your last sentence: “and full stack e2e tests that ensure that at all times our key user flows are working as expected.” – when you say “key”, how do you know when you’ve covered “enough” as there may be hundreds of flows with different permutations and variables (be it with data, users, timings, input methods, etc) that affect our end 2 end flows?

    Thanks!

    Like

    1. You are calling it the “testing pyramid”, but you are only talking about automation – Shouldn’t you be calling this the “automation pyramid”

      In previous posts I’ve included human testing in the pyramid either as an all-seeing eye or as a cloud at the top – I didn’t include it this time around so I’ve updated the post text to explicitly say ‘automated test pyramid’.

      how do you know when you’ve covered “enough” as there may be hundreds of flows with different permutations and variables (be it with data, users, timings, input methods, etc) that affect our end 2 end flows?

      An deadly yet easy-to-fall-into trap is automating everything as end-to-end tests as this means your test feedback time will be too long and the maintenance overhead too high.

      We focus on very broad but very shallow end to end scenarios – so we try to avoid different permutations, variables and input methods: focusing on the most common ones which we know through user analytics. For example, there’s six blog post formats on WordPress.com, but we only have an e2e test for the most popular format (standard post) – the particularities of the others are covered by unit tests of both the UI and REST API. If we had six end to end scenarios for creating a blog post our tests would take longer to provide us feedback, and we would need more work maintaining them.

      We apply this thinking to ensure we only cover key end-to-end scenarios, the key scenarios are things that our analytics show us that users do the most.

      You’d be surprised how few key end-to-end scenarios exist in reasonably large systems – even for a huge site like WordPress.com where our users create around ~55 million blog posts per month, we have about 15 end-to-end scenarios.

      As a user myself of many sites myself there’s very few key scenarios I commonly perform: that might be paying a bill and checking my bank balance, or checking my Facebook timeline and posting an update.

      Like

Comments are closed.