I tried to disambiguate Integration Testing from End-to-End Testing the other day. It was helpful for my own brain to finally have a way to bring a meaningful difference between these two things. I wrote:
Unit and end-to-end tests are the extremes on two sides of a spectrum. On the left, unit tests, little itty bitty sanity testers. On the right, end-to-end tests, big beefy (cough; sometimes flakey) tests that prove that lots and lots of systems are working together as intended and what a user experiences is in good shape.
I don’t mind the “spectrum” idea. There clearly isn’t just one kind of test, there are different types of tests for different reasons and they are all useful in different ways.
A pyramid is actually the more typical way to talk about this. The point of the pyramid is that it has this wide base at the bottom, and that represents unit tests because they are supposed to be foundational and you probably have a ton of them. At the top “User Interface Tests” (what I think a lot of people including me would call an “End to End Test”) of which you’ll have less of, in part because they are slower to run and test so many things you probably don’t need as many.
So… pyramid? spectrum? What are we going with here?
I have always found the Unit, Integration, and End to End testing pyramid to be a bit… clunky? The names describe how much you are testing, which is great, but it doesn’t give much perspective as to what you are actually trying to test.
Rather than give a name to a specific kind of test to describe how much you’re testing, name them according to what you are testing and why. So:
- Developer Interface Tests
- Consumer Interface Tests
- User Interface Tests
… maybe next time you don’t know how to write a test for a thing, you’ll ask yourself “Who am I writing this test for?”