Value of End to End Functional Checks
At the Agile 2009 conference I attended a workshop by Alro Belshee and Jim Shores on “Slow and Brittle: Replacing End to End Tests“. In this workshop they presented a couple of cases where End-to-End checking (testing) became a huge issues as the tests became slow, brittle and expensive. While I agree with them and have seen cases of checks (not just end-to-end checks) becoming a maintenance nightmare. Many times, checks create an illusion of safety, but really don’t add much value.
While some of it can be attributed to the poor scope/focus selection for checking (end-to-end or unit), I also think a lot has to do with poor skills, lack of understanding and rigid/flawed organizational structures.
During the workshop, the group I participated in, came up with following points as reasons why people write end-to-end checks:
- Document the interaction and intent
- Being Inclusive: Testers and Programmers can collaborate
- Scaffolding
- Good starting point for dealing with legacy code
- Early win: Easy to show people how to automate checking and get them started
- Good starting point to learn/explore more about the system
- Freedom and Confidence to Refactor code
- Ease: (sometimes they are very easy to create)
- Highlight Design Problems: If you see duplication in your tests, sometimes it could mean poor design.
I know other teams had several other interesting points. So the question is what other approach can you use to do away with end-to-end checking?
One of my proposals was to look more serious at “Eating your own dog food“. I also very much digg the idea about “Self-learning and Self-testing systems”.
