Miguel Juteau asks…
Some people contend that deploying markup code in production that contains automation hooks (e.g. Html5 data tags) is bad practice (for the same reason that we don’t deploy unit tests to production: it doesn’t serve the customer).
However it seems very desirable to build a solid contract for automation selectors that does not get affected by UI changes.
Any thoughts on that ?
I obviously don’t believe it’s bad practice to add testability features, such as HTML5 data attributes, to production code, that don’t directly serve the customer, otherwise I wouldn’t have shared an example of how I did this yesterday. I don’t like to encourage bad practices 🙂
However, I can see two potential reasons why people could believe this to be bad practice:
- Adding additional attributes to HTML5 elements adds to the size of the page, hence slows down the page for customers; and
- There is a potential opportunity cost of spending development resources on testability when they could be working on direct customer-facing functionality instead.
My views on these two potential arguments are:
- The example I gave yesterday of adding a data attribute would typically add ~50 Bytes (uncompressed) of data to the specific page. The current page size is ~313KB (~320,512 Bytes), which means the page size has increased by 0.015% by adding these attributes. I believe the testability benefit outweighs a 0.015% increase in page size.
- My primary role is that of testing, so when I add testability features to our application I am doing that as part of my role as a tester. Even if this were done by a development resource, I could argue that time spent adding testability features by a developer makes our application more testable, which means it’s more efficient and effective to test, which means it’s easier to find bugs, which means there will be less bugs. It is of my opinion that a customer who sees less bugs is being served well as a customer. I can’t see any point in deploying unit tests to production as they’re not a ‘deployable’ artifact (and we run them in a Continuous Integration environment before every release); however, we do run our automated end-to-end tests against production to ensure that we have a consistent end user experience.
I have also seen situations where adding testability features, such as progress indicators to make our automated tests more deterministic, also indirectly resulted in a large increase in usability for our customers by meeting this usability heuristic: “The system should always keep users informed about what is going on, through appropriate feedback within reasonable time”.