Agile Zone is brought to you in partnership with:

I am an author, speaker, and loud-mouth on the design of enterprise software. I work for ThoughtWorks, a software delivery and consulting company. Martin is a DZone MVB and is not an employee of DZone and has posted 82 posts at DZone. You can read more from them at their website. View Full User Profile

Broad-Stack Tests

04.25.2013
| 10312 views |
  • submit to reddit

A broad-stack test is a test that exercises most of the parts of a large application. It's often referred to as an end-to-end test or full-stack test. It lies in contrast to a ComponentTest, which only exercises a well-defined part of a system.

The difference between a broad-stack test and a component test is a continuum rather than a clear line. One area where bits can be missing from the fullness of the stack is how the test manipulates the application. Broad-stack tests often manipulate the application through a UI, such as testing web applications with tools like Selenium and Sahi. However a SubcutaneousTest can also be a broad-stack test if it continues to exercise most of the rest of the software. To further limit the scope, a test that exercises an application through a service interface can also be considered to be broad-stack test of the the server.

The other area where these tests don't cover the full breadth of the stack lies in connection to remote systems. Many people, including myself, think that tests that call remote systems are unnecessarily slow and brittle. It is usually better to use TestDoubles for these remote systems and check the doubles with IntegrationContractTests

Broad-stack tests have the advantage of exercising the application with all its parts connected together and thus can find bugs in the interaction between components in the way that component tests cannot. However broad-stack tests also tend to harder to maintain and slower to run than component tests. As a result the TestPyramid suggests using fewer broad-stack tests.

Published at DZone with permission of Martin Fowler, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)