Our website, like many other modern websites, allows users to leave positive and negative feedback on a given product. Higher-rated comments on any given product can provide a much needed boost in sales. As with any situation involving monetary incentives, someone will try to game the system and make money in the process. So, aside from the ability to leave a comment, our website has a rudimentary fraud prevention system. It will prevent any suspiciously duplicate comments/ratings from being added to any product.

It is now our task to test both of these features. So, let's explicitly state the target goals of the tests we will now implement:

We finished our two tests and we should now examine just how fragile they are. Even though the design of our tests made sense at the time of writing them, they will fail at the slightest provocation. Let's imagine a couple of real-life situations.

The sales team decided that having to change the amount of exclamation marks in the name of the product. These little tweaks happen all the time. We won't change the actual website, but we will change our test to expect a different amount of exclamation marks in the assertion. This will provide a sufficient discrepancy between the test and reality to make the test fail.

Let's change the assertion in test_add_new_review to look like this:

Running the tests will now give the following output:

Let's do a postmortem of our tests and list several bad mistakes:

The Chain Linked pattern is an improvement on the Spaghetti pattern. Unlike the bowl of spaghetti, an outstretched length of chain can characterize this pattern. Each link in the chain is an individual test and is an entity on its own. Even though each test is self contained and does not share too much with its neighbors, it still relies on a rigid order of execution. Most tests in this pattern rely on previous tests to set up the environment to be just right. This pattern is a huge improvement on the Spaghetti pattern in its long-term maintainability; however, since the whole test suite needs to be executed every time, it is neither efficient nor easy to use. In conclusion, the Chain Linked pattern might not be the best way to approach writing a test suite. However, it is an overall improvement over the Spaghetti pattern, since it segregates individual tests into more or less self-contained units.

Brian Foote and Joseph Yoder first popularized the Big Ball of Mud in their self-titled paper. Unlike the Spaghetti pattern, where the test suite can be separated into individual strands, Big Ball of Mud does not have any formal structures that will allow a distinction between any individual components. Test data and results are promiscuously shared amongst most distant and unrelated components until everything is global and mutable without warning. Unintentional test failures occur when a component is changed for a new test without the realization that hundreds of other tests depend on it. To exacerbate the problem, there is no easy way to find all of the interdependencies since everything is merged together like a piece of wet clay.

Adoption of this pattern is usually unintentional and stems from being developed over long periods of time with different individuals working on different pieces without any overall architectural plan. The initial success of just...