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.
With test-driven development being so prevalent today with Agile frameworks, it makes sense that Fowler would recommend that unit tests are created whenever a high-level test exposes a bug as it makes it much easier to focus on squashing the specific bug that was found in the high-level test. Fowler also makes a case for always trying to use tests that lend themselves well to the type of application you are developing. If it is a javascript program it is best tested using a javascript testing framework like Jasmine.
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.
Creative Coding 