Docs And Blog Posts

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
  • "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.

Misc

Tips and Terms and Tools

Sliming

  • 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

NCrunch

  • 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 .approved.txt instead of .received.txt, and the file not found error should go away.

GitHub Repos

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.