A Design Problem

This weekend, while in the middle of a deep dive into the practice of discovery testing on a personal project, I realised that there are different ways of building software from the ground up. That’s actually obvious because there are various programming languages and there are tons of frameworks for quickly constructing apps and sites. It’s literally never been easier to write software from scratch. But simple to start doesn’t mean that what we create turns out to be something that’s easy to maintain or extend, even if the team decides to write more tests or use more tools to monitor the sanity of the codebase. Even if user stories are clear and there’s enough capacity for testing, it can still be difficult to deliver changes without a hitch and on schedule, when the code makes it hard to do so.

For many testers and product owners who have never before looked at the code that runs the apps they test, it may be tough to see how simple feature requests take too long. It can be mind-boggling why bugs continue to creep in. We tend to just accept things as is. Finding out why is one reason I learned how to read and write code myself, besides the desire to have better communication with the devs I work with and having the ability to write my own tools to augment how I test. And after having been writing test code for a number of years now I can say that translating ideas into new code can be easy, but revising existing code to accommodate new business rules is often  troublesome. That means, at least for me, that I have a problem about the way I am writing code for the long haul, even if my app is working at present. I can imagine other programmers having the same predicament.

I now understand that writing long-term, maintainable, software is essentially a design problem. And it seems that a lot of us needs to up our skills in that area.

Bumping Into Discovery Testing

Until recently, what I mostly knew about test-driven development was the concept of red-green-refactor, unit testing application code while building them from the bottom-up. Likewise, I also thought that mocking was only all about mocks, fakes, stubs, and spies, tools that assist us in faking integrations so we can focus on what we really need to test. Apparently there is so much more to TDD and mocks that many programmers do not put into use.

Justin Searls calls it discovery testing. It’s a practice that’s attempts to help us build carefully-designed features with focus, confidence, and mindfulness, in a top-down approach. It breaks feature stories down into smaller problems right from the very beginning and forces programmers to slow down a little bit, enough for them to be more thoughtful about the high-level design. It uses test doubles to guide the design, which shapes up a source tree of collaborators and logical leaf nodes as development go. It favors rewrites over refactors, and helps us become aware of nasty redundant coverage with our tests.

And it categorizes TDD as a soft skill, rather than a technical skill.

He talks about it in more depth in a series of videos, building Conway’s Game of Life (in Java) as a coding exercise. He’s also talked about how we are often using mocks the wrong way, and shared insight on how we can write programs better.

Discover testing is fascinating, and has a lot of great points going for it. I feel that it takes the concept of red-green-refactor further and drives long-term maintainable software right from the start. I want to be good at it eventually, and I know I’d initially have to practice it long enough to see how much actual impact it has.