Home
Do you write end-to-end tests for critical happy-paths?
  v1.0 Posted at 3/05/2016 4:20 AM by Tiago Araujo

It’s not uncommon for critical workflows in projects to become flaky and brittle, and on occasion, this will not be caught until the product hits production.  An example of a critical workflow is placing an order on a shopping cart, or adding a timesheet in a time tracking site.
 
These are workflows that, if errors occur, the product becomes rather useless, and thus needs to be strongly tested.

The best way to test this workflow is by performing the workflow against a real environment, using a real browser – of course, in a repeatable, consistent way.
 
A nice option is to use Seleno​ with an appropriate web driver for the desired browser – see the Seleno documentation.  This library lets you write code to drive a user’s action in a browser, including  for example logging in, searching for a product, adding it to the cart, proceeding to checkout, entering test credit card information and ensuring the success message.
 
This isn’t free though.  The nature of these tests mean that without proper care and maintenance, tests will fail intermittently.  There are difficult-to-predict timings, DOM changes and browser compatibility issues and ongoing maintainability - so it is beneficial to limit these kinds of tests to critical happy-paths.
test-bad.png
Figure: Bad example - No end-to-end tests, no automatic feedback when things go catastrophically wrong
test-good.png
Figure: Good example - End-to-end Seleno tests run in Continuous-Integration, giving us very rapid feedback when the deployment breaks

Related rules

    Do you feel this rule needs an update?

    If you want to be notified when this rule is updated, please enter your email address:

    Comments:

    Note: Social Media login for Yotpo is not working in IE or Safari, please use Chrome. We are waiting for Yotpo to fix it.