Re: Which comes first: design skill or TDD?
JB,
I'm quite surprised by your second claim, that "One can learn design
skill by practising TDD".
Can you support that?
K
toggle quoted message
Show quoted text
On Tue, Jul 4, 2023 at 2:43?PM J. B. Rainsberger <me@...> wrote:
I am surprised to encounter so many people who claim something like this:
"You must understand how to design before you can practise TDD well."
I say the following in response:
- Practising TDD "poorly" still helps many programmers
- One can learn design skill by practising TDD, and I consider this a kind of pracitisng TDD "well"
- Your claim, framed that way, needlessly scares programmers away from TDD who need it
Practising TDD well and improving design skill forms an amplifying feedback loop, don't you think?
--
J. B. (Joe) Rainsberger :: tdd.training :: jbrains.ca ::
blog.thecodewhisperer.com
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
--
Kevin Rutherford
|
Which comes first: design skill or TDD?
I am surprised to encounter so many people who claim something like this:
"You must understand how to design before you can practise TDD well."
I say the following in response:
- Practising TDD "poorly" still helps many programmers - One can learn design skill by practising TDD, and I consider this a kind of pracitisng TDD "well" - Your claim, framed that way, needlessly scares programmers away from TDD who need it
Practising TDD well and improving design skill forms an amplifying feedback loop, don't you think? -- 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
|
Classifying tests: problem? solution? something else?
> 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?
I'm curious about this, because I hear it from time to time.
I have some questions, and we don't have to limit those to Tony, although I'm also interested in his replies:
1. What kind of "doesn't work"? It works for me, so maybe we have different ideas about how it could work or should work.
2. I classify tests in order to better understand all the different kinds of intent and purpose we have when we write them. This helps me decide how to choose which tests to write next. What challenges do you have with all these test classifications?
3. Some people report that there are too many test classifications to understand well. They become confused. I empathize. Why don't you simply ignore those classifications until you need them?
Finally, as for the difference between business and technical tests, when I talk about TDD I tend to focus on technical tests, because that's my context for TDD: to focus on the code. I handle Customer Tests (or business tests) quite differently, and I only sometimes practise what we've called Story-TDD or Acceptance-TDD. I practise it most often when I play the role of Customer for myself, such as on my volunteer projects. I try _very hard_ to clarify this for the people I teach, but I always run the risk that the message doesn't make it through. -- 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
|
I'd like to build on this in addition to echoing it.
Everyone, feel invited to join in. I'm asking everyone and not only George.
Which freedoms? Why do you care? What do those freedoms give you?
I have noticed these kinds of freedom:
- freedom from chasing after silly mistakes - freedom from having to "get it right" the first time - freedom from agonizing over design decisions - freedom from the blank page
Most of all, I enjoyed the freedom from thinking that I had to "be born with it" to design software systems well. This is the freedom I wish most to share with the most people. And that's why I teach TDD. -- 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.
On Mon, Jun 26, 2023 at 5:04?PM George Dinwiddie < lists@...> wrote: "That's what TDD is, you know.
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,
>
> 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?
>>
>> 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 :: tdd.training <>?::
>> <> ::
>> <>
>>
>
--
? ----------------------------------------------------------------------
? ?* George Dinwiddie *? ? ? ? ? ? ? ? ? ? ?
? ?Software Development? ? ? ? ? ? ? ? ? ?
? ?Consultant and Coach? ? ? ? ?
? ----------------------------------------------------------------------
--
J. B. (Joe) Rainsberger :: :: ::
Teaching evolutionary design and TDD since 2002
|
Re: Does an AI assistant help with learning/using TDD?
Hi there ?
A recent article I found quite interesting is the one by Roberto Ostinelli: he made a very insightful experiment using AI as a pair programming companion:
He set up an experiment where two AI chatbots pair on a kata autonomously, with one responsible for writing the next test and the other responsible for making it pass. Very impressive and fun to watch.
It's not a real TDD cycle (the refactor step is left at the end of the session), but I find the possibilities of using these tools as companions while coding interesting.
Coming back to the original question: I'm experimenting with ChatGPT as a conversational tool to help me clarify my intents, lay down more clearly the goals that I want to achieve and identify all the constraints of the problem that I want to solve, which is something I benefit from when doing TDD, especially when I ask myself "what is the next small problem that I want to solve?".
I agree with Matteo that these tools often give you a solution that is "too much" for your needs, but maybe by crafting the proper prompt you could instruct the AI to be more incremental and to think in small steps (which is something that lets them also work better, typically).
Cheers
Pietro
|
Re: Prompt: Why do you still care about TDD?
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
[Edited Message Follows]
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
- like fast/slow/io/non-io? business/technical?structure vs behaviour?
- what can tests/refactoring help to catch undefined/NPE at compile time more and not at runtime? (it's harder to refactor with dynamic language)
- how do we get fast feedback on things like build/infrastructure and security? Where tests are hard to write, and maybe technology is not there yet?
- how do I write tests that last longer? Like, communicate business intent and not internal details and technical details?
- TDD requires changing mindset, and it's hard to get adopt where psychological safety and maybe the technology doesn't support it.
- in the hostile codebase (with dynamic language), where there's no test and no psychology safety, how can I decouple the dependencies first to put in tests without breaking production code?
- How can TDD help me better organize/maintain the architecture where the layers/modules are separated clearly?
- how can TDD help me discover reinforcing loops (postive/negative) feedback loop faster? (like what's the core domain?)
Things I do like about TDD:
- easier to make change
- a safety net to protect me when my assumption is wrong or I make mistake, which I will
- better/easier to communicate the intent and collaborate with non-technical team members
|
Re: Prompt: Why do you still care about TDD?
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:
- You need to know how to design [yes also upfront], to understand how to create an emergent design.
- TDD is a tool to feel the weaknesses of your design but is not ensuring if your design is good.
- I still remember the great conversation around it stating correctly that ensuring decoupling is great but not
enough
- TDD more underrated part is
refactoring.
Everybody focuses on RED -> GREEN, and it ensures to follow customer needs and to avoid future regression,
but GREEN -> REFACTOR ensure the design evolves constantly, ensuring to grow with customer needs,
embracing the change. - TDD is a good tool to explore solution, but when my issue was the lack of knowledge of a certain technology it
becomes not so valuable to me. Yes, I still start my exploration from a test, but I need some anarchy to make tries and error cycles. This is mostly true during spikes.
- TDD is not a good tool for visual part of the application. It can be great on the visualization logic but not
to check if the visualization is correct: using tests for that it is too brittle to be reliable.
- TDD is still by far the best tool to produce software with a constant pace,
release continuously, ?share knowledge with coworkers when pairing, create trust with your stakeholders.
?
Ciao!
--
gk
?
?
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
|
Re: Prompt: Why do you still care about TDD?
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
--Ted M. Young (JitterTed) Principal Java Trainer & Coach Creator of
|
On Mon, Jun 26, 2023 at 6:21?AM J. B. Rainsberger < me@...> wrote: 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
|
Re: Challenges with TDD was Prompt: Why do you still care about TDD?)
Tony raises some interesting points. It does seem to me that people have different ideas about these issues.
On Jun 28, 2023, at 7:31 PM, Tony Vo <ttrung.vo@...> wrote:
[Edited Message Follows] 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
- like fast/slow/io/non-io? business/technical?structure vs behaviour?
My own preference is a simple division: ¡°pure¡± unit tests that only simulate I/O and timers, on the one hand, and end-to-end tests that mimic the way a user or other subsystem would interact with the one we¡¯re building. It¡¯s not always possible to make such a division perfect, but I¡¯ve had a lot of success with this approach. - what can tests/refactoring help to catch undefined/NPE at compile time more and not at runtime? (it's harder to refactor with dynamic language)
I don¡¯t really understand the problem here. If you are only coding in response to failing tests, aren¡¯t you generally forced to execute all code paths? I could see NPE¡¯s etc. happening because we¡¯re not perfect, of course. - how do we get fast feedback on things like build/infrastructure and security? Where tests are hard to write, and maybe technology is not there yet?
Nobody said it was always easy :) Can you provide some simple examples? My initial take is that this is what prototyping is for. Try the next thing, and when you understand it, delete the code you¡¯ve just written and start writing unit tests to force you to put it back (or at least, as much of it as is actually required). - how do I write tests that last longer? Like, communicate business intent and not internal details and technical details?
Again, I¡¯m not clear on what is being asked here. As far as I understand it, TDD is intended to drive business intent of the code, not the internal details or algorithms. Maybe examples would help here. - TDD requires changing mindset, and it's hard to get adopt where psychological safety and maybe the technology doesn't support it.
It absolutely does require changing mindsets, and that is one of the biggest obstacles to getting people to do it. But I have found that suitably motivated developers will spend the effort to learn it when they see it succeeding, in terms of higher throughput and better quality.? - in the hostile codebase (with dynamic language), where there's no test and no psychology safety, how can I decouple the dependencies first to put in tests without breaking production code?
Do read Michael Feather¡¯s ¡°Working Effectively with Legacy Code.¡± I have relied on it multiple times to deal with mature codebases without tests. - How can TDD help me better organize/maintain the architecture where the layers/modules are separated clearly?
- how can TDD help me discover reinforcing loops (postive/negative) feedback loop faster? (like what's the core domain?)
I¡¯m convinced that both of these have answers - but I don¡¯t think I understand the questions sufficiently. ----------------- 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!
|
I'm posting this for the benefit of those who follow the group via the online interface rather than as a mailing list as some of us do.... or is it just me? :-)
Groups.io makes it look like a forum rather than a mail list and allows you to edit a post. But if you do that, those who read it as a mail list get a new email each time. For example, I just got six copies of one post with minor changes, which is mildly annoying.
So, if this applies to you, please be aware of what happens when you edit and don't unnecessary changes after you have sent the post. If you have something that is important to correct, please make all your changes at once rather than piecemeal.
TIA for being considerate. :-)
Charlie
|
Re: Prompt: Why do you still care about TDD?
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
- like fast/slow/io/non-io? business/technical?structure vs behaviour?
- what can tests/refactoring help to catch undefined/NPE at compile time more and not at runtime? (it's harder to refactor with dynamic language)
- how do we get fast feedback on things like build/infrastructure and security? Where tests are hard to write, and maybe technology is not there yet?
- how do I write tests that last longer? Like, communicate business intent and not internal details and technical details?
- TDD requires changing mindset, and it's hard to get adopt where psychological safety and maybe the technology doesn't support it.
- in the hostile codebase (with dynamic language), where there's no test and no psychology safety, how can I decouple the dependencies first to put in tests without breaking production code?
- How can TDD help me better organize/maintain the architecture where the layers/modules are separated clearly?
- how can TDD help me discover reinforcing loops (postive/negative) feedback loop faster? (like what's the core domain?)
Things I do like about TDD:
- easier to make change
- a safety net to protect me when my assumption is wrong or I make mistake, which I will
- better/easier to communicate the intent and collaborate with non-technical team members
|
Re: Prompt: Why do you still care about TDD?
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.
|
Re: Prompt: Why do you still care about TDD?
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
|
| Jeff Langr / +1-719-287-4335
|
|
|
|
|
|
toggle quoted message
Show quoted text
June
26, 2023 at 10:59 AM Joe,
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
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
|
Re: Prompt: Why do you still care about TDD?
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
I care about it because:
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:
>
> 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?
|
Re: Prompt: Why do you still care about TDD?
I care about it because:
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.
toggle quoted message
Show quoted text
On Jun 26, 2023, at 9:21 AM, J. B. Rainsberger <me@...> wrote:
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?
|
Re: Prompt: Why do you still care about TDD?
"That's what TDD is, you know.
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."
toggle quoted message
Show quoted text
On 6/26/23 12:59 PM, George Dinwiddie wrote: Joe,
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?
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 :: tdd.training <>?:: jbrains.ca <> ::
blog.thecodewhisperer.com <>
--
----------------------------------------------------------------------
* George Dinwiddie *
Software Development
Consultant and Coach
----------------------------------------------------------------------
|
Re: Prompt: Why do you still care about TDD?
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: 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
-- Peace, Tim
-------------------------------------
|
Re: Prompt: Why do you still care about TDD?
On 2023-06-26 12:59, George Dinwiddie wrote: Joe,
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?
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? 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
|
Re: Prompt: Why do you still care about TDD?
Joe,
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
toggle quoted message
Show quoted text
On 6/26/23 9:21 AM, J. B. Rainsberger wrote: 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 :: tdd.training <>?:: jbrains.ca <> ::
blog.thecodewhisperer.com <>
--
----------------------------------------------------------------------
* George Dinwiddie *
Software Development
Consultant and Coach
----------------------------------------------------------------------
|
Re: Now that Reddit is dying...
I have a few small applications published in Apple¡¯s AppStore for iOS that are written entirely in Swift, and I used TDD from the very beginning to develop those applications. I tried to get my code coverage as high as possible, only there were certain areas were it just wasn¡¯t really practical to write tests. Those areas were in the minority, and what I discovered was that when I found bugs in my applications, those bugs were almost always in the code I did not or could not put under test.
toggle quoted message
Show quoted text
On Jun 26, 2023, at 06:15, J. B. Rainsberger <me@...> wrote:
Indeed, David, we have the Wiki Death Spiral problem: no readers, therefore no writers, therefore no readers.
As far as I know, there is only one solution: more reading and more writing. Pick one.
On Thu, Jun 22, 2023 at 4:00?PM David Koontz < david@...> wrote: Maybe it is my bad mood ... but lots of things are dying (just saw Google Domains sold to SqSpace are they still alive?) - and we humans are better at denial than acceptance as a WAY, as part of LIFE.? Death is nourishment for the young. As I look at the message list and count the messages/year ... it appears to have died again. I found this list via following JB's feed some where... and hoped I'd find some Swift Devs practicing Testing on here... that did not happen. I may linger on here for a while... but ... well the "space" seems empty.? Shout if you can HEAR US!
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
|
J. B. Rainsberger
Pietro Di Bello