Skip to content

Instantly share code, notes, and snippets.

@hanbzu
Created April 16, 2020 20:09
Show Gist options
  • Star 2 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save hanbzu/9bf2f8171210a385392643a103e578da to your computer and use it in GitHub Desktop.
Save hanbzu/9bf2f8171210a385392643a103e578da to your computer and use it in GitHub Desktop.
Some quotes about Test Driven Development (TDD) from DHH and Kent Beck.

Some quotes about Test Driven Development (TDD) from DHH and Kent Beck. They made a debate video or something. Source: https://martinfowler.com/articles/is-tdd-dead/

Code is not complete without tests, but that doesn't mean you need to write your tests first -- DHH

Examples, think of examples. Work from specific to general. But maybe not everybody is like that. -- Kent Beck

A design insight can allow you to do more fine-grained testing. -- Kent Beck

I mock almost nothing, going too deep in the mocking-path kills your ability to refactor. Your test cannot be coupled to the implementation. -- Kent Beck

Our style of TDD (because there are many), does not care very much about isolation. -- Martin Fowler

The most important thing is to have self-testing code, meaning that you run a single command and your whole project tests itself. Then the way to get there is secondary. TDD is only one of the ways. -- Martin Fowler

I may know exactly what I want or I may not know what I want. Feedback can come from different sides, like from looking at the page, seeing how it feels, etc. Then there's another feedback: have I broken anything? -- Martin Fowler

The question could be better framed as: the programmer is working on the code and what can they do for feedback? One way is TDD, another more traditional way is having QA people. One outcome of TDD is making programmers over-confident, so much that they thought they didn't need QA. The confidence comes from seeing all those green tests, but you know what? those tests are not catching all the user behaviour. -- DHH

What is the right ratio? Something is not right when I have these 4 lines of test code per 1 line of code. BDD is for sure an improvement, but when I want to change my functionality in that 1 line of code I still have to change and mantain those 4 lines of code. So the question is, what is the cost of such testing? Some code is worth 99.999 % of coverage while other code could be OK with significantly less than 60 % coverage. Then maybe that's the way I can recognise when it's worse to write and mantain those 4 lines of test code. I want to be able to answer: when is this piece of production code actually not worth writing the test for it? -- DHH

The sign of too little is that you cannot confidently change your code. The sign of too much is that you spend more time changing your tests than your production code. -- Martin Fowler

The discipline of working strictly for test first is a valuable thing to be able to do but it's not necessarily something that you want to do all the time. But once you're able to do it you have a wider range of options for your workflow. If I get into a tricky part of the code I know that I can work in that style. There're other styles that optimise other aspects. -- Kent Beck

Who's the audience and what do they need is a part of the trade offs here. -- Kent Beck

@wilsonsilva
Copy link

I mock almost nothing, going too deep in the mocking-path kills your ability to refactor. Your test cannot be coupled to the implementation. -- Kent Beck

THIS

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment