A blank page can be very intimidating, even for a Test-driven developer. Where do we start? Write a test, right? Not always.more...
Here is a video of my talk at the agile:Deliver conference 2019.
I’ve heard TDD learners say: “I don’t know what my code needs to do, how can I write a test? I need to write some code first.” I used to make a flippant reply to that, like: “You don’t know what your code needs to do! How could you possibly start with the code! Tests describe what the code must do. How can you write the code if you don’t know what the code is supposed to do?”
Sometimes, it’s simply a matter of software interface, boundaries and constraints understood or under your control. When it’s simply a matter of software, take some guidance from ZOMBIES! Start with the simplest cases (Zero and One) to get the Interface in place, generalize (to Many) and then make sure the anticipated Exceptional and Boundary cases are all covered with Simple test scenarios. ZOMBIES can really help, except when they can’t.
With my most recent green-field side-project, interacting with Commercial Off The Shelf hardware and software (COTS), I found that unknowns prevented me from writing tests. I totally get that helpless feeling (again) of not knowing what test to write! In Hexagonal Architecture (a.k.a. Ports and Adapters), we strive to separate the land where ZOMBIES rule and where we need something else. In the core of the hexagonal architecture, ZOMBIES rule, in the Adapters we need to discover what works.
In this session, we’ll look at how ZOMBIES help sneak up on the solution. In the adapters, we need a DIRECT approach to Determine, discover, and Isolate Risk, and Encapsulate Current Technology. DIRECT helps isolate and understand things out of our control.
In this talk we’ll explore the challenges and risks developing a real-time water pressure measuring system. We’ll look at how to get to a walking skeleton of the product together by discovering what is needed to get this stack of technologies elements working together:
- Analog to digital converter (ADC)
- Serial peripheral interface (SPI)
- IoT radio
- IoT mesh network
- Little Linux box
In a multi-layered system like this there are unknowns hide at every boundary. We’ll look at how we address the unknowns DIRECTly, striving to get to where ZOMBIES can guide. Integration is considered from the beginning because that is where the risk is.
There are more risks than strictly technical risks. Business risk assessment will impact technical choices. If we can build it, will it be affordable and profitable? How do we track progress in the face of significant risk. We’ll look at both the technical approach and how to keep progress and risk mitigation visible.
Published: August 03, 2020
Here is a short interview with James about TDD and embedded software from the deliver:Agile conference last spring.more...
James participated on these social media platforms.more...
Do you have some time to do a simple programming problem in C or C++ for my research?more...
My long-time good friend (Uncle) Bob Martin and I have fun programming together firing tracer bullets for distributed water pressure measurement system.more...
Here are a couple reviews of our TDD for Embedded C training.more...