They all warned me that this was a horrible idea, yet here I am, guided only by the determination to find the uncovered truth lying behind the stone walls erected by our ancestors centuries ago. I walk across the endless sweltering sea of sand, my skin boiling and the contents of my canteen running dangerously low. I continue for what feels like an eternity in the direction I had estimated the pyramid to be in, although after days of walking I am starting to have my doubts. As the last drop of my strength gives way I find a small dune to rest on. Hours pass as I bake in the desert sun knowing that I may never find the truth I am searching for. I open my eyes to find Martin Fowler reaching his hand out to me silently expressing his infinite knowledge of the desert I find myself in. Fowler hands me his flask of water and I feel my energy and determination replenish and we walk through the desert speaking very little, yet I know now that we will find the Great Pyramid of Software Testing.
To anyone reading this, I am deeply sorry that you had to read that little prologue, but I mean, how could I not make a desert journey scene when talking about the software testing pyramid. Anyways, fluff aside, I decided to read a post that Martin Fowler made in 2012 that is still extremely relevant today. As I am taking a software testing class currently I thought it would be interesting to see where the type of testing we have been doing fits into the actual pipeline of software development.
In Fowler’s article he talks about the differences between low-level unit tests, high-level UI driven tests, and everything in-between. The pyramid has unit tests on the bottom, acting as the base and where the majority of tests should be. Then, just below the GUI driven testing, comes service layer tests. These are tests that are generally API driven that don’t suffer from many of the problems that UI driven testing has. Lastly, the tip is where the UI tests are, these tests can prove to be useful but have many drawbacks.
UI tests are the most brittle of the three types of tests as many times moving an element of the UI can result in having to refactor most of your tests. Fowler describes high-level tests as a second line of defense. This can prove to be useful because if a high level test fails it can expose underlying holes in your unit tests.
Fowler’s article is filled to the brim with useful and topical information about testing. unit tests are the most flexible and powerful test type so it makes sense that anywhere a unit test could be used it should be. While the other two types of testing are less agile, they can provide benefits when usability is taken into account and only tests that make sense for UI level test are made.