BAU: Test-driven development

[mrwilson]

Content explaining what TDD is and why we advocate for it

[james-sheppard-gov-uk]

I very much support adding TDD to The GDS Way! When I learned about TDD it was with a peer group who benefitted from a lot of time and support from our managers, which included regular, safe opportunities to practise our TDD skills with expert advice. I wonder if guidance is needed for those who are new to TDD and/or haven't had any training or coaching in it?

[huwd]

Content looks great,

We might consider adding some links to some more pratical / worked examples?
I feel like folks can struggle translating the theory into that early practice of "simple test" -> "oh i didn't import from my lib file", "oh i didn't write a class", "oh i didn't initalise the class with the required parameter", "oh there's no method called sum" to get to that first green?

This page makes sense as a set of principles, but wonder if we can endorse a good worked example at the bottom that would help folks see the detail and build that muscle memory?

Can very much be added later.
Also a few nitpicks on Markdown formatting.

[mrwilson]

I very much support adding TDD to The GDS Way! When I learned about TDD it was with a peer group who benefitted from a lot of time and support from our managers, which included regular, safe opportunities to practise our TDD skills with expert advice. I wonder if guidance is needed for those who are new to TDD and/or haven't had any training or coaching in it?

I completely agree - I've added some sections about "Getting started" and "Getting better" but I had a similar experience - pairing/mobbing and TDDing every day, which turbocharged my learning.

I'd like us to do more training / support for people to get the same experience I did (which I'm also happy to do).

[mrwilson]

Content looks great,

We might consider adding some links to some more pratical / worked examples? I feel like folks can struggle translating the theory into that early practice of "simple test" -> "oh i didn't import from my lib file", "oh i didn't write a class", "oh i didn't initalise the class with the required parameter", "oh there's no method called sum" to get to that first green?

This page makes sense as a set of principles, but wonder if we can endorse a good worked example at the bottom that would help folks see the detail and build that muscle memory?

Can very much be added later. Also a few nitpicks on Markdown formatting.

Agree, I've linked two very good books (GOOS and By Example) but also Jason Gorman's page which has (a) his TDD book with many worked examples and (b) his 101 TDD Tips which is full of bitesize ... tips to improve your TDD.

[mboban2024]

I support this approach from a quality engineering and testing perspective. The content looks really good. To achieve good quality tests that drive development, it's crucial to create a testing mindset and culture. Without that TDD may fail to produce intended outcomes. Completely agree with principles and the value TDD brings, but it is important that teams don't misunderstand it as one-stop solution for all testing needs. Hence I think it’s worth also define what TDD is not, to clarify its boundaries or distinguish it from other types of testing in the software development lifecycle. A few suggestions:

• TDD is not a replacement for all test levels: TDD focuses on unit testing level and component integration. It doesn’t replace other levels of testing, such as functional integration testing, system testing, or feature acceptance testing. But good quality at unit testing reduces quality risk and extensive testing in higher levels
• TDD is not a replacement for exploratory testing: Exploratory testing is used to examine the application to find issues that automated tests may not capture. Exploratory testing uncovers unexpected behaviours outside the scope of TDD. It is a specialised task to prevent unknown - knowns (unaware of behaviour, but can exist in real usage) or unknown-unknowns (latent issues within our systems—problems we didn't even know could be problems or manifest when conditions line up just the right way) in the system.
• TDD is not a Catch-All for bugs: TDD helps prevent bugs in isolated units of code but does not catch all types of issues, especially those arising from system interactions or complex edge cases.
• TDD is more technically focused: Tests designed may miss view on business logic scenarios or user focused tests (else I think we need to experiment and evidence how module or class focused tests can have wider view on business and user needs).

[mrwilson]

Thanks @mboban2024! I will fold your suggestions into the content