I was listening to the Mob Mentality podcast on Spotify and came across this episode. Here is the YouTube link (Spotify is only audio): https://www.youtube.com/watch?v=_kL_tXiNcl4

The guest, Jason Swett, was talking about Test Driven Development and those coming into the fold, trying to learn it. He mentioned that most of the training out there when you search is focused around the Red, Green, Refactor cycle. He was thinking about a potential new model. It’s not thought through fully yet, but I really liked the concept.

Instead of this:

Red / Write a failing test, Green / Write production code to make the test pass, Refactor / Organize the code to be more efficient mentally or in terms of performance.

We have similar but slightly more focused:

Specify / Figure out how to specify your solution. What will it mean for your solution to work? (Not sure what the output of this is, I guess an understanding of what little thing you need to get done in domain specific language, like: Every line in this form needs to have a Cost Reference Number which will be unique per Phase. Maybe this could even be in the form of a comment, or part of your test naming conventions)

Encode / Write the code for that specification. (This is the test that you write to describe your specification from step 1)

Fulfill / Write the application code that will fulfill the specification. (This is the code in the program that the end users will use to fulfill and meet the specification.)

I think the reason I like that, and it is discussed in the podcast, is because Specify, Encode, Fulfill is immediately descriptive of what the process really needs to do. When I started writing tests, it was hard. I knew about the Red, Green, refactor cycle, but it’s super simple to write a test that fails but that has no bearing on what you really are wanting to do. If you don’t know what you want, you can still easily write a failing test which will end up serving no purpose.