Contents of this page:
- Docs And Blog Posts
- Mocks and TDD
- Ideas / Approaches
- Tips and Terms and Tools
- GitHub Repos
Docs And Blog Posts
- Different styles of TDD and when we should use them - talk by Sandro Mancuso
- The concept of self-testing code
- My refactoring article(s) on Martin Fowler's site
- My InSimpleTerms blog - TDD category (TDD category)
Recommended reads before Webinar panel on "Why hasn't TDD taken over the world yet?"
- research paper on TDD from Petr Jasek of Aalborg University, Denmark
- TDD techniques: http://codemanship.co.uk/parlezuml/blog/?postid=987
- Summary of the "Is TDD dead?" controversy started at RailsConf by David Heinemeier Hansson
- Martin Fowler's write-up of the debate about Is TDD Dead between himself, Kent Beck and David Heinemeier Hansson
- Kent Beck's sarcastic (but instructive) "TDD is dead" Facebook post
- Twitter thread started by Matt Wynne as input into our webinar, encouraging people to ask questions about TDD
- Twitter thread by Mike Hadlow: "I was a hard-core TDD evangelist. Now I realise it was all a mistake..."
- Response to that thread (not sure who from, sadly I lost the original tweet): "Comparing Peter Norvig and Ron Jeffries trying to write a sudoku solver is my favourite illustration of this"
Mocks and TDD
- Andy Longshaw: Reflections on brittle tests and mocking
- "When we came up with mocks, they weren't a TDD technique. They were a way to use TDD when designing the protocols between state machines. ... We designed mock frameworks to be a brutal early warning sign that our design was going off the rails." @natpryce
- @DeeJayGraham: "mocks should only be used in early development of code to help sketch out an interface quickly. Then code should be testable not to need them - contrary to previous popular advice to use mocks where things are “a bit hard” to test"
- @theMrTortoise: "When things are hard to test ... Refactor."
- @tooky "All this talk of TDD, how it makes you face your design, how test doubles make things brittle, when to use mocks, when not to use mocks. Reminds me to share @sandimetz' Magic Tricks of Testing: youtube / slide deck
- Unit Testing Principles, Practices, and Patterns by @vkhorikov
- @AndreasM_DK: "It might be tempting to mock away flakiness but... Simulate only things you completely understand - from @gojkoadzic - old but good"
- Mocks should be used to highlight how your object affects and is affected by other objects and to see how the state of other components is being affected.
- Mocks should not be exposing the innards of other objects.
- You should be putting most of your thought into the protocols between objects rather than the objects themselves.
- My original question on Twitter that led to some of the answers above
Ideas / Approaches
- Steve Freeman: "Early XP trainings used to include a week-long “pure” project to really get the flow."
- TDD techniques (ie Classic vs London): http://codemanship.co.uk/parlezuml/blog/?postid=987
- More on that, re double-loop and outside-in from Emily Bache
- "The problem is that the gap between katas and production code is still to big. Lately I've found mob programming in production code to be really effective. My current formula is katas + mob programming with someone who knows what they are doing." @emilybache
- "Moving from katas to real world problems, its important to know that you don't have to write the tests in programming languages. It could be in the domain language - or @emilybache's TDD with diagrams." @thebddadvocate
- "Approval testing is the term to google to learn more about how you could use sketches to do TDD" @emilybache
- "You can try ignoring the refactor step for a while and measure the difference. Using code complexity metrics etc." @thejonanshow
- On the idea that it's hard to convince stakeholders of the benefits of TDD because they think it will slow us down: "So, we are asking permission from management to think carefully? It makes my heart sink." @keithb_b Go slow to go fast.
Tips and Terms and Tools
- Sliming is the technique where you make your code do something trivial and hard-coded just to make your test pass - it's unlikely this will end up being production code. Nice description here from Denise Yu (scroll down a bit)
- "http://cyber-dojo.org is a great place to practice TDD." - @sebrose
- "Code retreat started by @coreyhaines is another fun way to learn." @thejonanshow
- File not found:
- If a test fails because a file was not found, it may be that you need to include a test file in your NCrunch settings:
- In Visual Studio:
- Extensions | NCrunch | Configuration
- In the top pane, double-click the shared settings for your project
- In the bottom pane, set "Additional files to include" in the General section.
- If you're using approval tests (as used by Gilded Rose), the first time you run the test it will create a "received" file (eg
ApprovalTest.ThirtyDays.received.txt). Create a copy of this with the suffix
.received.txt, and the file not found error should go away.
Sadly by necessity some of my repos are private. Those that are private are clearly marked. For those that are, please don't ask me to share the code, because I can't. They're listed here purely for my reference.