The Agile Testing Pyramid

 

The Agile Testing Pyramid

The testing pyramid is a model that has become popular over the years because it visually captures some of the trade-offs we face when writing automated tests.

We may want to write everything as a UI test. But that would hurt, as our feedback and ability to iterate quickly would really slow down. So we tend to use UI tests more sparingly.

We know however that we are going to have integration bugs, so we do need some kind of test that enables us to test that various things are connected and hooked up. That’s why we have integration tests.

But usually, the fastest and cheapest test we can write is the unit test. Which is why we like to do the bulk of our automated testing down there. Where the tests are fast and cheap.

So that’s it! That’s the testing pyramid.

The testing pyramid is great because helps get teams on the same page around how they’d like tackle automated testing for their project.

It can help by

·         Giving them a common language

·         Sharing rules of thumb around where and when to use different types of tests

·         And just generally save teams a lot of time and effort by being clear about what kinds of tests they want to write, and when.

 

UI test pros and cons

UI tests are fantastic and going end-to-end through the entire application, and ensuring that everything is hooked up and working. They are the deepest, most integrated kind of test we can write. And if an Ug works, chances are very good everything is going to work in production.tests

But this awesomeness comes with a price. UI tests are very slow. It takes orders of magnitude longer to run a UI test than a unit test. Which means once we start to collect a lot of these things, our build times start to get long, our ability to iterate really slows down.

They are always very fragile. Changing the user interface often breaks the corresponding UI tests. So we have to be careful about how we write these things, and try really hard not to make them overly fragile.

So because of their speed and fragility, we tend to use UI tests more sparingly, and save them end-to-end style smoke tests.

Integration test pros and cons

Integration tests like UI tests also test connectivity. But because they don’t go through the UI, there are no wherei and giving some level of confidence that things are things hooked up, without paying an exorbitant price.services, near as slow or fragile. These things are great and testing things like web

And while they are good at telling us when we have a problem, they unfortunately they can’t really tell us precisely where. As it could be anywhere in the system.

For low level precision, that tell us exactly where things went wrong, we rely on the unit test.

Unit test pros and cons

Unit tests are the fastest, most productive form of automated test we’ve got. These tests are fast, efficient, highly precise, and can pinpoint exactly where something fails when a test breaks. They give really rapid feedback. Are inexpensive. And developers write hundreds of these things all day long with testing their applications.

They’re only downside is that unit tests do periodically miss bugs that can sometimes occur only when you hook things up. Which is why integration and UI tests are still valuable. But for the bulk of our automated testing efforts, we should be relying on the unit test.

And when you bring these three forms of test together, and you try to balance some of these trade-offs that we just talked about, that’s when you begin to appreciate the testing pyramid.