Upon checking the fridge, to my horror, the egg trays are empty!
Just as I'm about to rush out to the nearest supermarket, I just remembered my stovetop broke down last night.
My instinct kicks in. Before I run towards the door, I quickly check the stovetop.
If it decides to take a holiday today, I'll surely head back to my bedroom and get more sleep.
Well, this is just an analogy.
Test tiers are usually made up of unit tests, integration tests and end-to-end tests (E2E).
And if we are to visualise the Agile Test Pyramid...
Integration test is an aggregation of unit tests that requires external resources. These resources could be transaction boundaries, filesystem or network calls. Resources are usually expensive to setup and perhaps torn down and they need to be made available to the integration test beforehand.
E2E tests for the whole workflow and may touch multiple integration points. It is usually more complex than an integration test. An example of E2E test is a test on checkout workflow. The test must log into the system, select a list of products, put them into the shopping cart then make a checkout.
As you can see, the test cases become more complex as we move up the tiers.
Many years ago, I said to my colleague that he needs to run the whole test suite before committing. He replied back saying, "But it takes too long to run the whole suite."
This made me realise that only a handful of people are willing to sit and wait while they twiddle their thumbs as they stare emptily at the screen. As for myself, I make a quick exit to the lift to get another cup of flat white.
From my experience, if test codes are grouped and ordered to run from bottom to the top of the pyramid, the development cycle will find and fix defects quicker and minimise waste.
You wouldn't run to the closest supermarket without ensuring your stovetop works, would you?
Below is an inverted test pyramid in running time.
No comments:
Post a Comment