Header Image

Gerard Meszaros

Independent Consultant, CTO & Author at FeedXL PTY LTD

Gerard Meszaros is an independent software development consultant and trainer with 30+ years experience in software and nearly two decades of experience in agile methods. He started doing eXtreme Programming in 2000 and quickly discovered that close attention to test code craftsmanship was essential to keep the cost of change low.  He described his key learnings in his book xUnit Test Patterns – Refactoring Test Code.  Since then he has turned his attention to applying the same concepts to organizing the automated acceptance tests as executable examples. He has coached teams and taught courses in North America, China, India, Japan and Europe. He is also the CTO and Product Owner of FeedXL.com which provides a web-based diet optimization tool for horses.

It Isn’t Testable Until It’s Tested

Mar 23, 2017

Testing complex systems is hard. Automating tests/checks for complex systems can be even harder. This is at least in part because of the difficulty involved in having the automate tests interact with the system-under-test to control its initial state, execute the logic in question, and inspecting the post-test state. And designing for testability in the abstract is hard to do in practice. There are so many ways to make a system hard to test!

The most sure-fire way to ensure a system is designed for testability is to drive the development of the system with automated tests, not at the unit-test level (TDD) but also at the system and component levels. What do these tests (or “examples”) look like? And how do they ensure testability of the system? That what I will be talking about.