Jakub Mrozek: Why Write Tests?
Imagine you work in a small IT company that has just finished an e-shop for an important client. The e-shop was originally schedule for release on Monday, but unfortunately was delayed (a classic situation).
Instead, the launch was moved back to the end of the week and an advertising campaign was prepare to start for the following Monday.
It’s Friday afternoon, the e-shop is completed and put into full operation, according to plan. One final test is run of the ordering process and new features without any problems occurring. Everyone leaves for the weekend, except for one colleague, who takes one for the team and remains available for any possible quick fixes that may be needed. Over the weekend, the e-shop will be checked a few times to make sure that everything is in working order.
Monday morning at work there’s an unusually pleasant atmosphere, until your project manager’s phone rings. After the first few seconds of the call, the project manager goes to view the administration of the e-shop and explains in a trembling voice that the problem has been checked.
The client is calling in to complain that the new e-shop system has not received a single new order, even though it’s almost Christmas and there are normally at least 500 new orders over the weekend. Your project manager tries to enter a new order and everything works seamlessly.
So, how is it possible that the database doesn’t show a single new order?
When you inspect the e-shop code, the programmers find a fatal error: the ordering process only works when the user is logged in as an administrator.
The project manager was logged in as an administrator when checking the function of the new features being added to the system, and nobody tested the process as a normal user after the final upgrade.
It’s a nightmare!
Confirmations of orders were only sent to the customers. There’s no copy for the admin of the e-shop since this feature was marked as low priority until next season. In other words, no one has any idea how many orders were made. Some customers have already paid for their orders, but the only information they know is the variable code of their order and the amount. There is no way to tell where orders should be sent. A real problem, since it’s right before Christmas.
Your company has to respond quickly.
So, what should you do? Announce the problems on the site? Customers have probably already stopped checking the site, so they won’t be aware of the problem. Send out an email to everyone who has signed up for a newsletter? Information about a problem like this could cost your client customers forever. It’s a critical situation.
Questions begin circulating: What happened? Why weren’t the goods sent out? Negative references about the e-shop start to appear and a few days later, a television report goes out about how this e-shop took money from its customers and never sent out their orders. Supplier errors? No one cares.
The e-shop of your client has lost its credibility: the goods remain on the shelves and no one wants to order anything.
It’s the end of the business.
How could this have been prevented? Writing a single test for one critical part of the whole system.
Instead, the e-shop failed because something remained in the source code that had no business being there: a command that only recognized orders from someone acting as an admin. If a few more minutes had been devoted to writing a test for the source code, none of this would have happened.
This article was originally printed in Czech and translated from Node Blog with permission from the author.
