Keyboard Shortcuts
Likes
Search
Prompt: Why do you still care about TDD?
|
Hi, folks. Why do you still care about TDD? Please skip the platitudes and write from the heart. Why does it still matter to you? Why do you still practise it? How does it still help? Why do you still teach it? Or not? -- J. B. (Joe) Rainsberger :: ?:: :: Replies from this account routinely take a few days, which allows me to reply thoughtfully. I reply more quickly to messages that clearly require answers urgently. If you need something from me and are on a deadline, then let me know how soon you need a reply so that I can better help you to get what you need. Thank you for your consideration. -- J. B. (Joe) Rainsberger :: :: :: Teaching evolutionary design and TDD since 2002 |
|||||||||||
|
Still works for me when I need absolute confidence and want to take small steps into a large problem. On Mon, Jun 26, 2023 at 4:21?PM J. B. Rainsberger <me@...> wrote:
|
|||||||||||
¿ªÔÆÌåÓýI have spent my career looking for ways to do software better - to improve productivity and quality and reduce rework. I tried all kinds of techniques, including formal structured analysis and design, and automated tools whose names I no longer recall. TDD is the first one I have found which actually delivers. It lets me build code more quickly and change it when needed.?I see unit tests as having four main functions: 1. regression detection (much faster than functional tests) 2. supporting refactoring 3. driving development 4. documenting behavior much more reliably than comments Unit tests that were created for the purpose of driving the code tend to be a better job at the other functions than do tests written afterwards for the purpose of improving code-coverage numbers. TDD also leads to software components built as components, with good information hiding. The usual proclivity of developers is to see a problem and immediately search for the algorithms and data structures needed to implement it - and those then become the core abstraction that the codebase must know. A change in algorithm for better performance then becomes a major deal. That should not happen with TDD used properly. ----------------- Author, HttpUnit <http://www.httpunit.org> and SimpleStub <http://simplestub.meterware.com> Now blogging at <http://russgold.net/sw/> Have you listened to Edict Zero <>? If not, you don¡¯t know what you¡¯re missing!
|
|||||||||||
|
On Mon, 26 Jun 2023 at 14:21, J. B. Rainsberger <me@...> wrote:
I use TDD because without it I feel increasingly uneasy, in the same way that I feel increasingly uneasy if I don't use version control. The longer I go without TDD, the less I trust my code and my design and the more stressed I get waiting for the inevitable screw-up. Frank. ? |
|||||||||||
|
I use TDD because like Russell, I have tried many things, including Structured Development, Model-Driven Development, CASE, Formal Specification, and many others. They have promised much and delivered little. TDD Just Works(TM). Fox --- On Mon, 26 Jun 2023, 15:52 Frank Carver via , <frank.carver=[email protected]> wrote:
|
|||||||||||
|
Joe,
toggle quoted message
Show quoted text
There are a lot of aspects I could mention, but it basically comes down to the fact that TDD made my software development joyful. The worrisome aspects were out of my head and into test code. - George On 6/26/23 9:21 AM, J. B. Rainsberger wrote:
Hi, folks. Why do you still care about TDD? --
---------------------------------------------------------------------- * George Dinwiddie * Software Development Consultant and Coach ---------------------------------------------------------------------- |
|||||||||||
|
On 2023-06-26 12:59, George Dinwiddie wrote:
Joe, I still care - for others. It seems to work well. Why not for myself? 95% chance I'll be retired within 3 months. -- 73 de KG2V Charles Gallo |
|||||||||||
|
Because it is refactoring-as-design. I can refactor immediately instead of waiting until the whole feature works, then adding enough tests that I can afford to do some refactoring late in the process, possibly months later if ever. On Mon, Jun 26, 2023 at 08:21 J. B. Rainsberger <me@...> wrote:
--
Peace, Tim ------------------------------------- |
|||||||||||
|
"That's what TDD is, you know.
toggle quoted message
Show quoted text
It's not just test cases and assertions and a suite and a test runner. That's what TDD needs. But what TDD is... is freedom." On 6/26/23 12:59 PM, George Dinwiddie wrote:
Joe, --
---------------------------------------------------------------------- * George Dinwiddie * Software Development Consultant and Coach ---------------------------------------------------------------------- |
|||||||||||
|
I care about it because:
toggle quoted message
Show quoted text
It helps me work in small steps, and small steps help me go faster. It gives me confidence in my code, so I am less tense and enjoy the work more. I feel sure that I make fewer mistakes when I am less tense. The tests support refactoring. Just today I wrote five articles on a very long sequence of refactoring steps. The tests staying green gave me the confidence to continue, and they quickly went red a few times when I misstepped. I'm a better programmer when I use TDD. R sent from iPad, probably via Mars. Errors, if any, are not mine. ronjeffries@... is a better address for me, maybe. On Jun 26, 2023, at 9:21 AM, J. B. Rainsberger <me@...> wrote: |
|||||||||||
|
Once upon a time, I cared about TDD. In fact, I moved from being a frontend game developer ?towards more server side and business applications, in part so that I could take advantage of TDD. I tried TDD in some flash games, it kinda worked.? I tried TDD in a unity game.? It did not go well. TDD server side, is always fun, and is great at helping me ask questions for what we are really trying to accomplish. Nowadays, I don't care about TDD per say anymore. I certainly don't/cant' follow the textbook definition of it most of the time. My definition of what is a "test" has expanded?beyond the unit test suite.? For me, now, I care about fast feedback loops. And automated fast feedback loops when possible. For example, Angular has an ecosystem designed around testing, but the test infrastructure is horribly slow.? I'd much rather use vite without a test suite, keeping a page open that is constantly refreshing, than attempt to use the Angular set of tests. Fast feedback loops, small changes, early API usage, automated regression, and safe refactoring. That's what I care about. Right now I work on platforms, where everything is live integration. It's easier to use TDD in such an environment than it was in Unity or mobile game development, but my localized, automated tests never give me the confidence that is needed, since the real deployment of the platform is never the same as my sanitized, modular tests. So I need to find new tools that provide fast feedback loops, small changes, early API usage, automated regression, and safe refactoring in every new context. brought to you by the letters A, V, and I and the number 47 On Tue, Jun 27, 2023 at 12:33?AM Ron Jeffries <ronjeffriesacm@...> wrote: I care about it because: |
|||||||||||
¿ªÔÆÌåÓýI'll second what George said. I also find it very gratifying--joyful even--to be able to whittle code into something elegant yet direct.Regarding teaching it, it's extremely rewarding seeing people latch onto TDD--whether it's in the short-term of 3 days worth of training, where you see light bulbs go on and people start to lower their resistances, or whether it's in the long-term of someone who has become "infected for life." Cheers, Jeff
|
|||||||||||
|
Like others: it removes the fear, helps me think about design, and makes change easier (more like: a little less hard). I also enjoy that code under test is code that has been used in two slightly different contexts already. Why I value this also has to do with design. In a way it invites me to repeatedly think about coupling. Another point I enjoy is that it is the best way I know of to communicate intents and keep the communication rolling when I code with others (pair, ensemble). And when I practice during a kata, it helps make the practice deliberate. The TDD loop format invites to explicit intent and regular "where am I, where do I want to go" pauses. |
|||||||||||
|
Things I don't like about TDD: - I think the test name separation by unit test/integration test/micro test/behaviour test doesn't work, but I'm not sure what's the "sensible" way to separate them yet |
|||||||||||
|
TDD is the only process I know that helps me, personally, deal with otherwise crushing perfectionism and anxiety. The fact that Red->Green means I can do whatever I want, ugly or not, messy or not, duplicated or not, as long as the test passes, has been the only thing that lets me continually move forward in development. It encourages me to take smaller (safer) steps, sidestepping my loss aversion. It offers the freedom to perfect (not make perfect) the code using refactoring, a process that I take great joy in doing. It still does those things, more than it did 5 years ago and 10 years ago (i.e., I get better every year). I have yet to find or be shown another way that gets me all of what I get from TDD. I still teach it, because I've seen other people struggle with getting [overcomplicated] code to work and it's the only way I know how to get out of that trap. ;ted --
On Mon, Jun 26, 2023 at 6:21?AM J. B. Rainsberger <me@...> wrote:
|
|||||||||||
¿ªÔÆÌåÓýAll XP practices need to exit from the comfort zone, they need courage and, If you are brave enough, the reward is high. I started practicing TDD in 2004 ¨C 2005. Back then, there was the false idea that doing TDD, the application design would have magically become great, no architecture ideas would be needed, and a world of unicorns would have open in front of you to be blessed forever in enlightenment. ? Guess what? It wasn¡¯t true. ? My opinions about TDD:
? Ciao! -- gk ? ? From:
[email protected] <[email protected]> on behalf of J. B. Rainsberger <me@...> Hi, folks. Why do you still care about TDD? ? Please skip the platitudes and write from the heart. Why does it still matter to you? Why do you still practise it? How does it still help? Why do you still teach it? ? Or not? J. B. (Joe) Rainsberger ::
?::
::
? Replies from this account routinely take a few days, which allows me to reply thoughtfully. I reply more quickly to messages that clearly require answers urgently. If you need something from me and are on a deadline, then let me know how soon you need a reply so that I can better help you to get what you need. Thank you for your consideration.
|
|||||||||||
|
Hi Tony, I'm 100% with you on the things you like. When I don't do TDD (see below) I get very very uncomfortable WRT my code. This comment made me think... > - I think the test name separation by unit test/integration test/micro
test/behaviour test doesn't work, > but I'm not sure what's the "sensible"
way to separate them yet > - like fast/slow/io/non-io? business/technical?structure vs behaviour? That's interesting. TDD, at least as I learned and know it, doesn't spell out any particular way to separate different kinds of tests. In XP (which is where I learned TDD) there are only two kinds of tests spelled out: so-called "unit tests" and "acceptance tests". This classic distinction was seen as based on "intent". That is, "unit tests" were intended to capture the developer's intention while acceptance tests were for the customer. Sometimes different tools were used for each, sometimes the same tool was stretched to cover both. "Unit tests" was a terrible name at the time, because it meant something entirely different to the community of testers. It still isn't a very good one AFAIC. But I still consider the division by intent to be the most important categorization for a very practical reason: the "unit" tests have to pass 100% all the time, while the acceptance tests don't - and won't until the project is complete. Within those two categories, I think any separation is really up to you and will vary by project. You mention some areas (infrastructure, security) where you find it hard to write tests. Welcome to the club! We all - even those of us who have done it for years - have such areas. That's the primary reason why even now I occasionally don't use TDD... if I don't know how to write a test for a particular thing, then I have to do without it for a time. After I manage to create the code TDDlessly, I'll go back and figure out how I might have written the tests. That can be a fairly significant effort. As an example, almost 20 years ago, I didn't know how to TDD a Windows Forms user interface. The event-driven part seemed particularly hard. My job required me to actually get work done so I wrote the code first and the tests second. Later, when I had time, I went back and figured out how I could have done it using TDD in the first place. For later projects with the same technology I was able to use TDD and ended up creating a course on TDDing windows user interfaces. TDD was invented many years before many of the technologies we are using today. It's up to us to figure out how to make it work with those technologies and - in some cases - to create the tools. Charlie On Wed, Jun 28, 2023 at 4:31?PM Tony Vo <ttrung.vo@...> wrote:
|
J. B. Rainsberger
Frank Carver
Sleepyfox