Łukasz Makuch

In his book "Thinking, Fast and Slow", the Nobel Prize-winning psychologist Daniel Kahneman writes about the idea of substitution. It's a mechanism that enables us to quickly answer difficult questions by replacing them with similar, but easier questions. For example, when asked if it makes sense to invest in Apple stock, we may say whether we like Apple products, without even noticing that we didn't answer the original question. Recently it occurred to me that this phenomenon may be observed in testing front-end applications as well.

The front-end world is evolving rapidly. We can see people from various backgrounds getting into it. Some of them, including myself, used to be back-end developers. When facing a serious challenge, such as "How do I test this application?", having some experience in a similar field puts us at risk of unconsciously answering a different question, like "Which parts of this application do I know how to test?".

If we know how to test a method returning an integer, we may try to interact with a front-end application as if it were an object with a method returning an integer. For example, we may count the number of table row nodes in the DOM, without even checking that they are rendered one after another instead of on top of each other. Or if we are no strangers to string comparison, we may settle for checking if the value of a DOM Text node matches our expectations, without verifying that the font is readable.

Does that make the tests we write useless? Not necessarily. They may be testing something after all. When in doubt, I ask myself whether I'd still write similar assertions even if the code I think I'm testing didn't run in a browser. Looking from 30 000 feet, would the tests still look the same, even if the app was a command-line utility or a REST API? If yes, then I may be testing everything but the very front end of my front end. And if that question doesn't help, I use the font-weight benchmark for front-end tests.