While there are still vocal proponents of #TDD, #BDD, #ExtremeProgramming & variations, it struck me today that people getting into software development now probably don’t realize how hyped those concepts were a decade-ish ago. These days they feel more like a personal preference for some than an organizational, or even team, decision.
I’d attribute some of that to the shift towards statically types languages, but also that the developer role today feels more individualistic in general.
Encouraged by people like @jasongorman, I'm giving #TDD a proper go during the scarce free time of my parental leave.
So far it's rubbing me all the wrong ways. The bottom-up approach runs very counter to my preferred way of thinking, where I sketch out the big picture and then fill out the details.
On the other hand, in the couple of hours it took me to recreate a part of a hobby project, it uncovered a design flaw that would have taken me an order of magnitude more hours to rectify later. 😍
It baffles me how easy some people are to dismiss techniques and perspectives that are advocated by developers as "something for developers" and thus not for business or product management:
These are all concepts meant to improve delivering the right product and delivering the product right. Thinking it's merely developers doing their thing outside the realm or concern of product management is so detrimental to both.
I’ve seen a lot of wrong takes on test driven development, or #TDD, lately. Surprising, given that it’s just 3 simple steps to remember:
Write a unit test before writing code
Write the code to be tested
Tell everyone you’re doing TDD. Tell your friends, your family and your colleagues. Most importantly, tell the internet. Everyone must know you’re doing TDD. This is the most important step, and in fact, you can probably skip the first two steps and go straight to this one.
I know exactly what the problem is with eForth: I’m testing manually by poring over emulator execution traces; I’m not writing tests. I know the inner interpreter and some code words work, so I guess I’ll have to write a test framework out of that, and then test the effects of every other word until I’ve worked it all out. #TDD#FORTH
> After 2 decades of doing TDD and BDD, I've realized that ignoring design and thinking that TDD will do a decent job at it for a trade-off for quicker/higher-quality development with the extra time was entirely a scam.
I react in two ways:
Yes, ignoring design seems risky and invites failure.
I don't know how to "do TDD and BDD" while ignoring design.
On the contrary, I do and teach #TDD as a mechanism for learning how to design "better".
An underrated approach to test-driving code is taking advantage of unrolled loops.
This pairs extremely well with the zero, one, many approach where you start with the empty case, then add logic to support a single input, then add logic to support two inputs, and so on.
We can use this approach to de-risk the jump from "single input" to "multiple inputs".
if (input.size() == 1) {
// One element case
else if (input.size() == 2) {
// Two elements case
} else if (...) {
// And so on
}
Our goal, then, is to refactor the contents of each block to look as similar as possible, such that extracting out a loop rather than a multi-step conditional is a task that can be delegated to your tooling or IDE.
Structuring your incremental test-drive development in this way may seem counter-intuitive, but it's another example of staging out low-risk changes and refactoring duplication out into a clearer form.
The feeling when you bang your head against the wall for 3 hours and then just try something, but don't really believe in it and suddenly all your unit tests pass! 🎉 :awesome:
This is the beauty of #TestDrivenDevelopment - you can just try and guess until it works.😄 It's such a funny experience!
Last year I did #AdventOfCode live streams, working to solve them as quickly as possible when the problems went live.
I usually get to some point where the problems hit skills I don't have (usually math skills) which often led to struggle streams that inevitably gets cut off so I can just go think about the problem.
I also did one after the fact video about applying #tdd to AoC. I decided this year that's all I'm going to do: a handful of problems from a TDD perspective, to teach technique.
I feel like #TDD it’s a moving target for me working in a legacy code base. I am constantly pleasantly surprised when my tests save my skin and I can refactor things with some confidence. But writing the tests and writing them well is so hard, when there is no underlying design in the project to follow 😅
What’s a good place to go from zero to hero with TDD in #dotnet projects? Any reasonably priced courses or tutorials to recommend?
I think one of the biggest shifts over the past year in how I write server-side generated HTML (Thymeleaf + Spring MVC) is trying to completely avoid any decision-making logic (is there any other kind? 😏) in the template, and push all of the logic into the back-end (Controller or DTO).
This may not always be possible, but it does mean that such logic is much easier to test (and therefore test-drive).
I’m hosting Chris Simon on a #JetBrains#livestream to discuss #TDD, #DDD, and #csharp. Not to be confused with D&D, which is about wizards, dragons, and dungeon masters… wait it's pretty similar.
I never understood the request for "empirical studies" to prove this or that in software development, e.g.:
"Show me an unbiased experiment with measurable outcomes that proves that TDD makes a dev team more productive. Until then, I'll continue doing what I do now."
Let's flip that around:
"Show me an unbiased experiment with measurable outcomes that proves doing [whatever your current process is] makes a dev team more productive than doing TDD."
Unless you can do those experiments (which are extremely difficult to do), you can't use the claim that since there is no "TDD works better" study, that means that it must be worse than what you're currently doing. That's what philosophers call an "appeal to ignorance".
TDD might be worse; you might have a great process! (In which case, I'd love to try it out!) On the other hand, TDD might be better, and you're missing out on improving. Without the (possibly impossible) empirical evidence, you have to try it and see.
Gifted myself the book about PyTest by @brianokken (because I was not busy enough with all of my personal projects 😂 ). Hope this test doesn't fail: assert is_good_book.
Test Driven Development sometimes is a huge disappointment to me:
I was writing the test first, and then got really surprised that the new method can’t be called because it’s kinda not implemented. How can that be?! 😠
ICYMI: Got a pre-commit hook that runs #JUnit5 tests? Try "When All Tests Were Green". It's trivial to add to your build, requires no change in human behavior, and by the end of Day 1 will have saved you more time than it cost to set up.
There are some really great coders who don’t get #TDD and that’s OK but I wish they would not use that misunderstanding to just proclaim that it is useless. On the other hand we need to find a way to prove the usefulness without just saying that “you are holding it wrong”. #programming