Comments by "Daniel Sandberg" (@ddanielsandberg) on "Do People HATE Test Driven Development (TDD)?" video.

  1. Why would that happen? With TDD we take many small steps and make many small tests. While the task/feature may be incomplete, the build passes the tests. public void sortNothingShouldReturnEmptyList() { assertThat(sort(null), is(emptyList())); } and write some production code that passes the test... You can commit that if you like, but that would be silly unless it's lunch. :)
    3
  2. I really recommend people to watch these two presentations by GeePaw Hill and Joe Rainsberger. - TDD & The Lump Of Coding Fallacy / geepawhill - Some Underrated Elements of Success for the Modern Programmer - J. B. Rainsberger - KanDDDinsky 2018 / youtube
    2
  3. Structure it a little bit to help everyone out. We are trying start our commits with a ticketID or a keyword like: - "GG-117: Add feature flag 'processing.useAsyncRunner'" - "GG-117: Add async implementation of Transaction Processing" - "GG-365: Fallback handler for uncaught API errors" - "GG-117: Remove duplication" - "GG-117,Fix,Bug,Performance: Fix edge-case where async processing sometimes never finishes" - "GG-365: Add pretty print to error messages" - "Refactor: Remove dead code" - "Churn: Fix linting/static analysis warnings" We are in the process of implementing some policies and rules so that there has to be a valid ticket or approved "keyword" for every commit. This way we can also perform change-archeology even without feature branches. Then let him continue to work on long-lived feature branches himself. He'll come around once he realizes the rest of you are happier, gets more done, can move and adapt faster. "You can't convince anyone of anything. You can only give them the right information, so that they convince themselves."
    2
  4. The "red" part of the TDD cycle is what tests the tests. If the requirements are wrong, then the code and the tests need to be changed or replaced. And TDD is primary goal of TDD is not really testing, but has more to do guiding the design of the software over the entire lifecycle of the product. Now, if you've been coding for 20 years, done a whole bunch of TDD, then you know what good testable code looks like and can get away with writing tests after the fact. That however falls apart fast if you have mixed experience levels in the team. I wonder why programmers has no particular feelings against changing the code when requirements changes, but when tests has to change (or thrown away) it's suddenly a horrible death of waste. I get the feeling that it has more to do with trying convince themselves "it's bad" so they don't have to do that scary thing they don't wanted to do in the first place.
    1