PubMob session: Evolutionary Design Without Tests

I love TDD. Not everyone does. Sometimes we just want to practise guiding a design to evolve without spending time to write tests. I don’t recommend this as a way to work, but I understand why you might prefer it, especially if you’ve been practising TDD for a while and worry that it still just… feels… so… slow. Sometimes it helps to spend time focusing on guiding a design to evolve using tiny steps, frequent commits, and a trusted guide. (That’s me!)

We’ll work in Java, because compile-time type checking helps make this safer. We’ll work on my teaching example, because I know it well and consequently we’ll be able to get moving sooner. But you’ll drive—and when you go down a dusty road, I’ll be there to help you get back on track. Just keep this in mind: without tests, we’ll need to take teeny, tiny steps just to be safe. Don’t worry: I trust you.

What Do You Mean by “Without” Tests?

I would like to explore two key questions: when do we truly need automated tests and which habits do we (collectively) have that compensate enough for not running automated tests? Accordingly, I propose the following basic rules:

• We don’t write automated tests. We already know how to live with them; let’s explore life without them.
• We try not to run the code at all. We try to convince ourselves that the code is correct merely by looking at it. This will affect how we change the code as well as how we organize the code.
• If we run the code, then we decide whether to run the entire application or execute code in a REPL. When we run the code, we discuss why we needed to run the code.

Let me be clear about a few things. These sessions are not a recommendation to stop writing automated tests. These sessions are not trying to “prove” anything about TDD or not TDD. My goal here is to focus on letting the design evolve while putting extra pressure on us to keep the design really simple. Can we make the design so simple that we can feel confident enough just by looking at it? If yes, then how? If not, then why not? And if it’s complicated, then let’s learn more about what makes it complicated. In the meantime, we’ll focus on good design principles, accurate refactoring, and we’ll work in really small steps.

Hop On and Hop Off… Any Time!

Please feel welcome to join us any time, as often as you like. Although we are working on a long-running project, you don’t need to worry about joining us part-way through. The strength of the ensemble lies partly in helping new folks feel comfortable contributing—a you always have me as both your coach (I help you drive) and Customer (I choose details about features).