Re: Searching for a book that helps introduce JavaScript or Java Programming?
Josue - thanks this a gem. Since Jeff is on this (I think) we can just ask him to update his book for my daughter. Jeff - Thanks in advance for updating your book for a 16yr :-)
Cheers
Mark
|
Re: Searching for a book that helps introduce JavaScript or Java Programming?
For Java:
Agile Java: Crafting Code with Test-Driven Development -??
It is the one that I indicate when they ask for a book to learn Java. As I think to learn any language it is important to start together?with tests (because code without tests is legacy code), I tend to appreciate this kind of book.
The problem is that it seems there is no updated?version of the book. It's very old Java. When I was teaching using this book as a base, I helped the?trainers to change the language?constructs to more modern ones. Maybe it could be a problem for a beginner?alone.
Em qui., 22 de jun. de 2023 ¨¤s 18:24, Mark Levison < mark@...> escreveu:
On the weekend I was helping my youngest daughter with an unfairly difficult programming project for Gr 11 Computing Science. They were expected to write a web application that retrieves data from a data source on the internet. A list of potential datasources was given, but they hadn't been well tested since several we tried wouldn't answer the programs request. The truly unfair part was that they were expected to understand how to retrieve data asynchronously. Too bad they had never been taught about async. Our final body of code was 100 lines of JavaScript and another 100 of html/css.
?
On the way we encountered a JavaScript function that took a boolean parameter, so the code read like: FooBar(..., True). We discussed why this is a poorly written function and then I promised: "I promised even if I'm fifty years dead, I will return from the grave too haunt her if she ever writes a method that accepts a boolean parameter." The laughter that followed is what started our quest. She would like a book(s) that will help learn to be a good programmer. We already have Petzold's Code 2nd Edition on order. (Her call not mine).
?
Where else would you go for: program design, opinion around good/bad practice (and why)? Strong preference for an example driven book. As it stands?
?
So far I've looked at:
- Headfirst JavaScript - Chapter 8 before we start building something noticeable
- Joy of JavaScript - Larsen (Manning) - starts with a solid example in ch1. _This could be good, although I already see the code is missing modern things like let _
- Wes Bus online courses - I've seen two people suggesting his material is it good?
- - _can't tell if it is good or just long_
?
Discarded:
- - Not convinced the quality is even
?
Along with JavaScript, Java is the other programming langauge that she will learn next year, any books there??
|
Personally, I tried very hard to work with TDD within the Actionscript community, but I was never able to find a job where the team I joined already did TDD. When flash stopped being a viable career, I pivoted towards back end systems instead of frontend, in hopes of finding teams that did TDD.? I never found them. But I was able to practice it on my own even if the rest of the team didn't.? Now I'm back in a field where TDD isn't easily accessible. (devops/platforms) From what I've seen others do, if it interests you, I would recommend starting a TDD meetup for IOS and see if you can't use that to find the places you want to work, or discover there isn't enough interest for it. Personally, the TDD meetups I went to never had more than 2 or 3 people from the same company showing up, but I hear in other locations it's very different. brought to you by the letters A, V, and I
and the number 47
On Mon, Jul 10, 2023 at 9:07?PM Dan Torres < danstorre@...> wrote: Hello! I'm Dan Torres, an iOS developer very interested in TDD. I've used it for the last 3 years and it has changed my life for the better. One of my problems is that the iOS industry is not interested in TDD, and I'm wondering if I should continue learning and writing?more about TDD or continue the industry and write about iOS frameworks only.
It's interesting because I really thought that reaching this point (where I can do?TDD and even teach it) I'd find a functional team that follows these things, but I think that's not possible anymore.
Should I even change my tech stack? I would happily do so If I'm able to find a team that practices TDD, that would be the dream.
Regards,?
Dan Torres
El lun, 10 jul 2023 a las 11:25, Groups.io Notification (< [email protected]>) escribi¨®:
Hello Dan Torres,
Thank you for your interest in the /g/testdrivendevelopment group at Groups.io. If you did not request or do not want to join [email protected], please ignore this message.
If you only want to send and receive messages from [email protected], reply to this email to confirm your email address and activate your membership.
If you want to use the resources and read messages on the website, please click on the link below to confirm your email address, set up a password, and choose other subscription settings:
Confirm account
Cheers,
The Groups.io Team
|
Hi Dan! Good to see you here!
I would recommend connecting with Jon Reid if you haven't already, he is sharing a lot about TDD on iOS. Here are some links:
twitter -> @qcoding
mastodon -> iosdev.space/@qcoding
That might help you get in touch with a wider group of ppl doing TDD on iOS.
Cheers!
Jov
|
Perfect, Thank you again for the wise words Charlie.
Really appreciate it!
I will continue my journey, I know how to find a job and I will continue putting myself out there writing?about TDD and how it helps not only the code but the team and ultimately the business.
Regards,
Dan
Hi Dan,
That's why I added the provision that it might be harder these days. Some of us have been around a fairly long time, so you might need a time machine. :-) But I still think it's important to remember that you only need to find one good job at a time and that doing what is popular doesn't always lead to the best personal outcomes.
FWIW, I was a coach / consultant after around 1995, so I didn't need to find a job - just a gig. I only needed to find places that _wanted_ to use those practices and needed help doing it. I know a number of others here found their work happiness the same way. :-)
Charlie
Charlie
On Mon, Jul 10, 2023 at 12:00?PM Dan Torres < danstorre@...> wrote: Interesting thank you so much Charlie!,
May I ask how you ended up these teams? I'd love to be part in a XP even XPish team.
P.D. Jon Reid invited me to this group and I'm very glad and honour to be here actually.
Regards,
Hi Dan,
None of us can tell you what you _should_ do, but we can tell you what has worked for us. :-)
For me, I've been happiest doing work that I like, in the way that I like. That ended up being TDD in an XP or XP-ish environment. Not everyone wanted that and many who said they did ended up only wanting to use the terminology but not truly implementing it.
My theory was always that I only needed one job at a time and something always turned up. Someone else will have to say whether times have changed too much for that approach, but I'm pretty sure that
doing what you want to do is still better than not doing it. :-)
Charlie
On Mon, Jul 10, 2023 at 11:07?AM Dan Torres < danstorre@...> wrote: Hello! I'm Dan Torres, an iOS developer very interested in TDD. I've used it for the last 3 years and it has changed my life for the better. One of my problems is that the iOS industry is not interested in TDD, and I'm wondering if I should continue learning and writing?more about TDD or continue the industry and write about iOS frameworks only.
It's interesting because I really thought that reaching this point (where I can do?TDD and even teach it) I'd find a functional team that follows these things, but I think that's not possible anymore.
Should I even change my tech stack? I would happily do so If I'm able to find a team that practices TDD, that would be the dream.
Regards,?
Dan Torres
El lun, 10 jul 2023 a las 11:25, Groups.io Notification (< [email protected]>) escribi¨®:
Hello Dan Torres,
Thank you for your interest in the /g/testdrivendevelopment group at Groups.io. If you did not request or do not want to join [email protected], please ignore this message.
If you only want to send and receive messages from [email protected], reply to this email to confirm your email address and activate your membership.
If you want to use the resources and read messages on the website, please click on the link below to confirm your email address, set up a password, and choose other subscription settings:
Confirm account
Cheers,
The Groups.io Team
|
Hi Dan,
That's why I added the provision that it might be harder these days. Some of us have been around a fairly long time, so you might need a time machine. :-) But I still think it's important to remember that you only need to find one good job at a time and that doing what is popular doesn't always lead to the best personal outcomes.
FWIW, I was a coach / consultant after around 1995, so I didn't need to find a job - just a gig. I only needed to find places that _wanted_ to use those practices and needed help doing it. I know a number of others here found their work happiness the same way. :-)
Charlie
Charlie
On Mon, Jul 10, 2023 at 12:00?PM Dan Torres < danstorre@...> wrote: Interesting thank you so much Charlie!,
May I ask how you ended up these teams? I'd love to be part in a XP even XPish team.
P.D. Jon Reid invited me to this group and I'm very glad and honour to be here actually.
Regards,
Hi Dan,
None of us can tell you what you _should_ do, but we can tell you what has worked for us. :-)
For me, I've been happiest doing work that I like, in the way that I like. That ended up being TDD in an XP or XP-ish environment. Not everyone wanted that and many who said they did ended up only wanting to use the terminology but not truly implementing it.
My theory was always that I only needed one job at a time and something always turned up. Someone else will have to say whether times have changed too much for that approach, but I'm pretty sure that
doing what you want to do is still better than not doing it. :-)
Charlie
On Mon, Jul 10, 2023 at 11:07?AM Dan Torres < danstorre@...> wrote: Hello! I'm Dan Torres, an iOS developer very interested in TDD. I've used it for the last 3 years and it has changed my life for the better. One of my problems is that the iOS industry is not interested in TDD, and I'm wondering if I should continue learning and writing?more about TDD or continue the industry and write about iOS frameworks only.
It's interesting because I really thought that reaching this point (where I can do?TDD and even teach it) I'd find a functional team that follows these things, but I think that's not possible anymore.
Should I even change my tech stack? I would happily do so If I'm able to find a team that practices TDD, that would be the dream.
Regards,?
Dan Torres
El lun, 10 jul 2023 a las 11:25, Groups.io Notification (< [email protected]>) escribi¨®:
Hello Dan Torres,
Thank you for your interest in the /g/testdrivendevelopment group at Groups.io. If you did not request or do not want to join [email protected], please ignore this message.
If you only want to send and receive messages from [email protected], reply to this email to confirm your email address and activate your membership.
If you want to use the resources and read messages on the website, please click on the link below to confirm your email address, set up a password, and choose other subscription settings:
Confirm account
Cheers,
The Groups.io Team
|
Interesting thank you so much Charlie!,
May I ask how you ended up these teams? I'd love to be part in a XP even XPish team.
P.D. Jon Reid invited me to this group and I'm very glad and honour to be here actually.
Regards,
Hi Dan,
None of us can tell you what you _should_ do, but we can tell you what has worked for us. :-)
For me, I've been happiest doing work that I like, in the way that I like. That ended up being TDD in an XP or XP-ish environment. Not everyone wanted that and many who said they did ended up only wanting to use the terminology but not truly implementing it.
My theory was always that I only needed one job at a time and something always turned up. Someone else will have to say whether times have changed too much for that approach, but I'm pretty sure that
doing what you want to do is still better than not doing it. :-)
Charlie
On Mon, Jul 10, 2023 at 11:07?AM Dan Torres < danstorre@...> wrote: Hello! I'm Dan Torres, an iOS developer very interested in TDD. I've used it for the last 3 years and it has changed my life for the better. One of my problems is that the iOS industry is not interested in TDD, and I'm wondering if I should continue learning and writing?more about TDD or continue the industry and write about iOS frameworks only.
It's interesting because I really thought that reaching this point (where I can do?TDD and even teach it) I'd find a functional team that follows these things, but I think that's not possible anymore.
Should I even change my tech stack? I would happily do so If I'm able to find a team that practices TDD, that would be the dream.
Regards,?
Dan Torres
El lun, 10 jul 2023 a las 11:25, Groups.io Notification (< [email protected]>) escribi¨®:
Hello Dan Torres,
Thank you for your interest in the /g/testdrivendevelopment group at Groups.io. If you did not request or do not want to join [email protected], please ignore this message.
If you only want to send and receive messages from [email protected], reply to this email to confirm your email address and activate your membership.
If you want to use the resources and read messages on the website, please click on the link below to confirm your email address, set up a password, and choose other subscription settings:
Confirm account
Cheers,
The Groups.io Team
|
Hi Dan,
None of us can tell you what you _should_ do, but we can tell you what has worked for us. :-)
For me, I've been happiest doing work that I like, in the way that I like. That ended up being TDD in an XP or XP-ish environment. Not everyone wanted that and many who said they did ended up only wanting to use the terminology but not truly implementing it.
My theory was always that I only needed one job at a time and something always turned up. Someone else will have to say whether times have changed too much for that approach, but I'm pretty sure that
doing what you want to do is still better than not doing it. :-)
Charlie
On Mon, Jul 10, 2023 at 11:07?AM Dan Torres < danstorre@...> wrote: Hello! I'm Dan Torres, an iOS developer very interested in TDD. I've used it for the last 3 years and it has changed my life for the better. One of my problems is that the iOS industry is not interested in TDD, and I'm wondering if I should continue learning and writing?more about TDD or continue the industry and write about iOS frameworks only.
It's interesting because I really thought that reaching this point (where I can do?TDD and even teach it) I'd find a functional team that follows these things, but I think that's not possible anymore.
Should I even change my tech stack? I would happily do so If I'm able to find a team that practices TDD, that would be the dream.
Regards,?
Dan Torres
El lun, 10 jul 2023 a las 11:25, Groups.io Notification (< [email protected]>) escribi¨®:
Hello Dan Torres,
Thank you for your interest in the /g/testdrivendevelopment group at Groups.io. If you did not request or do not want to join [email protected], please ignore this message.
If you only want to send and receive messages from [email protected], reply to this email to confirm your email address and activate your membership.
If you want to use the resources and read messages on the website, please click on the link below to confirm your email address, set up a password, and choose other subscription settings:
Confirm account
Cheers,
The Groups.io Team
|
Hello! I'm Dan Torres, an iOS developer very interested in TDD. I've used it for the last 3 years and it has changed my life for the better. One of my problems is that the iOS industry is not interested in TDD, and I'm wondering if I should continue learning and writing?more about TDD or continue the industry and write about iOS frameworks only.
It's interesting because I really thought that reaching this point (where I can do?TDD and even teach it) I'd find a functional team that follows these things, but I think that's not possible anymore.
Should I even change my tech stack? I would happily do so If I'm able to find a team that practices TDD, that would be the dream.
Regards,?
Dan Torres
El lun, 10 jul 2023 a las 11:25, Groups.io Notification (< [email protected]>) escribi¨®:
Hello Dan Torres,
Thank you for your interest in the /g/testdrivendevelopment group at Groups.io. If you did not request or do not want to join [email protected], please ignore this message.
If you only want to send and receive messages from [email protected], reply to this email to confirm your email address and activate your membership.
If you want to use the resources and read messages on the website, please click on the link below to confirm your email address, set up a password, and choose other subscription settings:
Confirm account
Cheers,
The Groups.io Team
|
Re: Classifying tests: problem? solution? something else?
Possibly that is why in XP we called them programmer tests and customer tests. :) On Jul 6, 2023, at 12:28 PM, Russell Gold <russ@...> wrote:
I see those as:1) tests that ensure that the code does what the developers intend it to do, and 2) tests that ensure that the code does what the users expect it to do.
Ron Jeffries
If it is more than you need, it is waste. -- Andy Seidl
|
Re: Classifying tests: problem? solution? something else?
Rather than categorical classification, perhaps it is useful to think of "axes" of test strategy (plural of "axis", not "axe"):
The main ones in my mind are... 1. Collaboration: How many production objects/classes/modules are exercised in the test? 2. I/O: How much access to?disk/network/clock/etc. happens during the test? ... as well as: 3. Doubles: How many interactions with test versions of other objects/classes/modules does the test need to set up to do its job? How complex is the usage of test doubles?
I think of (3) as mostly something to be minimized(*), whereas there are legit tradeoffs along the first two axes.
(*) "minimized" does not mean "completely avoided".
Some combinations of these qualities, or "points" in my imaginary 3D testing strategy problem space:
Low collaboration, no I/O, no doubles:? What almost everyone would call a "unit" or "isolated test".? High design pressure on unit boundaries. The code under test is essentially a pure function -- the "core" of functional core/imperative shell design.
Low collaboration, no I/O, with doubles:? When testing impure production code, there is likely some setup (axis 3). High design pressure, high coupling. Examples: integrations with the outside?world. Valuable if done well, very easy to do poorly.
Low collaboration, with I/O Tests of adapters to owned/easy to setup up resources (ie database wrappers) Low design pressure. Valuable in small quantity, can be costly to maintain.
High collaboration, low/no I/O Tests of subsystems, often with fakes of modules that use I/O in production. Low design pressure, low coupling, high support for structural refactoring. This is one place where test doubles?(fakes! not mocks or spies!) are very useful in my practice. Extremely valuable and underused in my opinion. That said, there is a danger of neglecting lower-level design/testing.
High collaboration, high I/O "End to end" or "integration tests". No design pressure. Danger of neglecting lower-level design/testing. False sense of security. Fool's gold. "Easy" to write, sort of, brittle, provide no design guidance. WAY overused in my experience.
On Tue, Jul 4, 2023 at 6:39?AM J. B. Rainsberger < me@...> wrote: > 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
|
Re: Classifying tests: problem? solution? something else?
I see those as: 1) tests that ensure that the code does what the developers intend it to do, and 2) tests that ensure that the code does what the users expect it to do.
toggle quoted message
Show quoted text
On Jul 6, 2023, at 12:22 PM, Tim Ottinger <tottinge@...> wrote:
I'm a bear of little brain.?
There are tests that are fast & good enough to support refactoring (only, maybe): you can happily run them after renaming a variable.
There are tests that show that the system's functions work, and which aren't fast enough to run them after a variable rename.
Both are important. Ultimately there are "the system works" and there are "the refactoring step didn't break anything" and the rest is just intent and technology. In the past two years, where I have been working on a codebase with hundreds of thousands of tests and almost a hundred different teams touching it, I started to ¡°care less¡± about semantically classifying tests. That, team members can come up with an agreement of what makes more sense to them in their context. Do we really need to have a single classification company-wise?
Nowadays, I really care about classifying tests in terms of their infrastructure costs. This matters globally and must defined at company level, because although code isn¡¯t (well, sometimes is) shared among teams, resources are. Reliability is also another category that I care. Your want the tests you run in the pre-merge to give you 100% sound signal.
Do we allow multithreading in our unit test suite, or should these tests be somewhere else? Do we allow mock server in it? When do we need to run all the tests and when can we just run a subset of them? How can we bring (costly) integration tests to the pre-merge? What to do with flaky tests; should we delete them, should we keep them there waiting for someone to fix them, should we move them to another place? These are questions that have been on my mind when I talk about segregating tests.
Cheers, Mauricio?
On Tue, 4 Jul 2023 at 18:19, George Dinwiddie < lists@...> wrote: I agree that the naming can be confusing because often the same name?
means different things to different people. I don't get too hung up on?
the naming of types of tests (though I love Gpaw's "microtests" because?
it gets out of the "unit test" mire). Instead, I tray to talk about the?
meaning the other person has behind the name.
When I started doing TDD, I sorted my tests into three categories:
??- "unit tests" which tested in memory code without any other dependencies
??- "database tests" which tested code dependent on the database. This?
led me to using the Adapter Pattern so I could isolate my unit tests?
from the database and test only the adapter against a real database.
??- "deployed tests" which required the system to be deployed in order?
to run. These tended to be "story tests," though I found that by?
delegating from the requirements of the app server (J2EE in those days)?
to Plain Old Java Objects with the same API, I could implement most of?
the story tests the same way as unit tests, so "story tests" became?
another category.
Eventually I had need to call other systems beyond the database, so?
those became another classification of tests, but done in the same?
fashion as the database tests.
??- George
On 7/4/23 9:38 AM, J. B. Rainsberger wrote:
>? > 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 yetlike 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 :: tdd.training <>?::?
>??<> ::
>??<>
>?
> 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
>?
--?
??----------------------------------------------------------------------
? ?* George Dinwiddie *? ? ? ? ? ? ? ? ? ? ??
? ?Software Development? ? ? ? ? ? ? ? ? ??
? ?Consultant and Coach? ? ? ? ?
??----------------------------------------------------------------------
-- Maur¨ªcio AnicheAuthor of?
--?Peace, Tim
-------------------------------------
|
Re: Classifying tests: problem? solution? something else?
I'm a bear of little brain.?
There are tests that are fast & good enough to support refactoring (only, maybe): you can happily run them after renaming a variable.
There are tests that show that the system's functions work, and which aren't fast enough to run them after a variable rename.
Both are important. Ultimately there are "the system works" and there are "the refactoring step didn't break anything" and the rest is just intent and technology.
In the past two years, where I have been working on a codebase with hundreds of thousands of tests and almost a hundred different teams touching it, I started to ¡°care less¡± about semantically classifying tests. That, team members can come up with an agreement of what makes more sense to them in their context. Do we really need to have a single classification company-wise?
Nowadays, I really care about classifying tests in terms of their infrastructure costs. This matters globally and must defined at company level, because although code isn¡¯t (well, sometimes is) shared among teams, resources are. Reliability is also another category that I care. Your want the tests you run in the pre-merge to give you 100% sound signal.
Do we allow multithreading in our unit test suite, or should these tests be somewhere else? Do we allow mock server in it? When do we need to run all the tests and when can we just run a subset of them? How can we bring (costly) integration tests to the pre-merge? What to do with flaky tests; should we delete them, should we keep them there waiting for someone to fix them, should we move them to another place? These are questions that have been on my mind when I talk about segregating tests.
Cheers, Mauricio?
On Tue, 4 Jul 2023 at 18:19, George Dinwiddie < lists@...> wrote: I agree that the naming can be confusing because often the same name
means different things to different people. I don't get too hung up on
the naming of types of tests (though I love Gpaw's "microtests" because
it gets out of the "unit test" mire). Instead, I tray to talk about the
meaning the other person has behind the name.
When I started doing TDD, I sorted my tests into three categories:
? - "unit tests" which tested in memory code without any other dependencies
? - "database tests" which tested code dependent on the database. This
led me to using the Adapter Pattern so I could isolate my unit tests
from the database and test only the adapter against a real database.
? - "deployed tests" which required the system to be deployed in order
to run. These tended to be "story tests," though I found that by
delegating from the requirements of the app server (J2EE in those days)
to Plain Old Java Objects with the same API, I could implement most of
the story tests the same way as unit tests, so "story tests" became
another category.
Eventually I had need to call other systems beyond the database, so
those became another classification of tests, but done in the same
fashion as the database tests.
? - George
On 7/4/23 9:38 AM, J. B. Rainsberger wrote:
>? > 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 yetlike 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 :: tdd.training <>?::
> <> ::
> <>
>
> 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
>
--
? ----------------------------------------------------------------------
? ?* George Dinwiddie *? ? ? ? ? ? ? ? ? ? ?
? ?Software Development? ? ? ? ? ? ? ? ? ?
? ?Consultant and Coach? ? ? ? ?
? ----------------------------------------------------------------------
-- Maur¨ªcio AnicheAuthor of
-- Peace, Tim
-------------------------------------
|
Freedom to focus on one thing at a time.
- what am I building?
- what defines success--how will I know when the code works?
- how do I describe that? how will I interface with that?
- how do I code that?
- does it work?
- did I inadvertently break anything else?
- are there opportunities to improve the design?
- are there opportunities to improve clarity for us all?
- what's the next small increment that will move the system forward?
That's a lot of stuff to remember. And yet the ingrained cycle of TDD
means I don't ever forget what questions
are or where I am.
Freedom to think.
Cheers,
Jeff
|
| Jeff Langr / +1-719-287-4335
|
|
|
|
|
|
toggle quoted message
Show quoted text
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. -- J. B. (Joe) Rainsberger ::
::
:: Teaching
evolutionary design and TDD since 2002
|
Re: Classifying tests: problem? solution? something else?
I have similar ideas. Classifying tests in terms of where in the pipeline they are most helpful in terms of ensuring quality makes most sense to me.
That classification?would be something?like "build", "pre-push", "pre-merge", "pre-deploy", "post-deploy" and "monitoring-production" (periodic runs reporting to a monitoring tool).?
In the past two years, where I have been working on a codebase with hundreds of thousands of tests and almost a hundred different teams touching it, I started to ¡°care less¡± about semantically classifying tests. That, team members can come up with an agreement of what makes more sense to them in their context. Do we really need to have a single classification company-wise?
Nowadays, I really care about classifying tests in terms of their infrastructure costs. This matters globally and must defined at company level, because although code isn¡¯t (well, sometimes is) shared among teams, resources are. Reliability is also another category that I care. Your want the tests you run in the pre-merge to give you 100% sound signal.
Do we allow multithreading in our unit test suite, or should these tests be somewhere else? Do we allow mock server in it? When do we need to run all the tests and when can we just run a subset of them? How can we bring (costly) integration tests to the pre-merge? What to do with flaky tests; should we delete them, should we keep them there waiting for someone to fix them, should we move them to another place? These are questions that have been on my mind when I talk about segregating tests.
Cheers, Mauricio?
On Tue, 4 Jul 2023 at 18:19, George Dinwiddie < lists@...> wrote: I agree that the naming can be confusing because often the same name
means different things to different people. I don't get too hung up on
the naming of types of tests (though I love Gpaw's "microtests" because
it gets out of the "unit test" mire). Instead, I tray to talk about the
meaning the other person has behind the name.
When I started doing TDD, I sorted my tests into three categories:
? - "unit tests" which tested in memory code without any other dependencies
? - "database tests" which tested code dependent on the database. This
led me to using the Adapter Pattern so I could isolate my unit tests
from the database and test only the adapter against a real database.
? - "deployed tests" which required the system to be deployed in order
to run. These tended to be "story tests," though I found that by
delegating from the requirements of the app server (J2EE in those days)
to Plain Old Java Objects with the same API, I could implement most of
the story tests the same way as unit tests, so "story tests" became
another category.
Eventually I had need to call other systems beyond the database, so
those became another classification of tests, but done in the same
fashion as the database tests.
? - George
On 7/4/23 9:38 AM, J. B. Rainsberger wrote:
>? > 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 yetlike 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 :: tdd.training <>?::
> <> ::
> <>
>
> 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
>
--
? ----------------------------------------------------------------------
? ?* George Dinwiddie *? ? ? ? ? ? ? ? ? ? ?
? ?Software Development? ? ? ? ? ? ? ? ? ?
? ?Consultant and Coach? ? ? ? ?
? ----------------------------------------------------------------------
-- Maur¨ªcio AnicheAuthor of
|
Re: Classifying tests: problem? solution? something else?
Totally worth you?Maur¨ªcio there.
Having been responsible (inherited) for a 40 min test suite on an app worked on by hundreds of devs: determinism and cost were high on my priority list.
Fox ---
In the past two years, where I have been working on a codebase with hundreds of thousands of tests and almost a hundred different teams touching it, I started to ¡°care less¡± about semantically classifying tests. That, team members can come up with an agreement of what makes more sense to them in their context. Do we really need to have a single classification company-wise?
Nowadays, I really care about classifying tests in terms of their infrastructure costs. This matters globally and must defined at company level, because although code isn¡¯t (well, sometimes is) shared among teams, resources are. Reliability is also another category that I care. Your want the tests you run in the pre-merge to give you 100% sound signal.
Do we allow multithreading in our unit test suite, or should these tests be somewhere else? Do we allow mock server in it? When do we need to run all the tests and when can we just run a subset of them? How can we bring (costly) integration tests to the pre-merge? What to do with flaky tests; should we delete them, should we keep them there waiting for someone to fix them, should we move them to another place? These are questions that have been on my mind when I talk about segregating tests.
Cheers, Mauricio?
On Tue, 4 Jul 2023 at 18:19, George Dinwiddie < lists@...> wrote: I agree that the naming can be confusing because often the same name
means different things to different people. I don't get too hung up on
the naming of types of tests (though I love Gpaw's "microtests" because
it gets out of the "unit test" mire). Instead, I tray to talk about the
meaning the other person has behind the name.
When I started doing TDD, I sorted my tests into three categories:
? - "unit tests" which tested in memory code without any other dependencies
? - "database tests" which tested code dependent on the database. This
led me to using the Adapter Pattern so I could isolate my unit tests
from the database and test only the adapter against a real database.
? - "deployed tests" which required the system to be deployed in order
to run. These tended to be "story tests," though I found that by
delegating from the requirements of the app server (J2EE in those days)
to Plain Old Java Objects with the same API, I could implement most of
the story tests the same way as unit tests, so "story tests" became
another category.
Eventually I had need to call other systems beyond the database, so
those became another classification of tests, but done in the same
fashion as the database tests.
? - George
On 7/4/23 9:38 AM, J. B. Rainsberger wrote:
>? > 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 yetlike 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 :: tdd.training <>?::
> <> ::
> <>
>
> 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
>
--
? ----------------------------------------------------------------------
? ?* George Dinwiddie *? ? ? ? ? ? ? ? ? ? ?
? ?Software Development? ? ? ? ? ? ? ? ? ?
? ?Consultant and Coach? ? ? ? ?
? ----------------------------------------------------------------------
-- Maur¨ªcio AnicheAuthor of
|
Re: Which comes first: design skill or TDD?
However, it very concretely enables fast feedback loops. The fastest available anywhere.
My feeling is that we over-promise a bit on the feedback loops. Automated mistake detectors provide a pretty strong signal in the event of a "refactoring" that instead moves one or more measurements out of tolerance. But signals about design errors?? My experience, and my survey of the literature, suggests those signals are actually pretty weak. The Koss/Martin bowling game exercise offers one candidate example, where a compiler error triggered a re-evaluation of the use of "value objects" in the API; you'll have to consider whether reverting to a general purpose data structure was a design improvement or not....
|
Re: Classifying tests: problem? solution? something else?
In the past two years, where I have been working on a codebase with hundreds of thousands of tests and almost a hundred different teams touching it, I started to ¡°care less¡± about semantically classifying tests. That, team members can come up with an agreement of what makes more sense to them in their context. Do we really need to have a single classification company-wise?
Nowadays, I really care about classifying tests in terms of their infrastructure costs. This matters globally and must defined at company level, because although code isn¡¯t (well, sometimes is) shared among teams, resources are. Reliability is also another category that I care. Your want the tests you run in the pre-merge to give you 100% sound signal.
Do we allow multithreading in our unit test suite, or should these tests be somewhere else? Do we allow mock server in it? When do we need to run all the tests and when can we just run a subset of them? How can we bring (costly) integration tests to the pre-merge? What to do with flaky tests; should we delete them, should we keep them there waiting for someone to fix them, should we move them to another place? These are questions that have been on my mind when I talk about segregating tests.
Cheers, Mauricio?
On Tue, 4 Jul 2023 at 18:19, George Dinwiddie < lists@...> wrote: I agree that the naming can be confusing because often the same name
means different things to different people. I don't get too hung up on
the naming of types of tests (though I love Gpaw's "microtests" because
it gets out of the "unit test" mire). Instead, I tray to talk about the
meaning the other person has behind the name.
When I started doing TDD, I sorted my tests into three categories:
? - "unit tests" which tested in memory code without any other dependencies
? - "database tests" which tested code dependent on the database. This
led me to using the Adapter Pattern so I could isolate my unit tests
from the database and test only the adapter against a real database.
? - "deployed tests" which required the system to be deployed in order
to run. These tended to be "story tests," though I found that by
delegating from the requirements of the app server (J2EE in those days)
to Plain Old Java Objects with the same API, I could implement most of
the story tests the same way as unit tests, so "story tests" became
another category.
Eventually I had need to call other systems beyond the database, so
those became another classification of tests, but done in the same
fashion as the database tests.
? - George
On 7/4/23 9:38 AM, J. B. Rainsberger wrote:
>? > 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 yetlike 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 :: tdd.training <>?::
> <> ::
> <>
>
> 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
>
--
? ----------------------------------------------------------------------
? ?* George Dinwiddie *? ? ? ? ? ? ? ? ? ? ?
? ?Software Development? ? ? ? ? ? ? ? ? ?
? ?Consultant and Coach? ? ? ? ?
? ----------------------------------------------------------------------
-- -- Maur¨ªcio AnicheAuthor of
|
Re: Which comes first: design skill or TDD?
I¡¯d actually say TDD doesn¡¯t TEACH much. It helps reinforce teachings you should know. ¡ª ? Charlie 73 de KG2V Http://www.thegallos.com
toggle quoted message
Show quoted text
On Jul 5, 2023, at 1:39 PM, Sleepyfox <sleepyfox@...> wrote:
? But TDD doesn't teach you about coupling and cohesion, it doesn't teach you about 'clean code' (whatever you determine that to mean), it doesn't even teach you about removal of duplication - that's Simple Design.
Fox On Wed, 5 Jul 2023, 17:27 Russell Gold, < russ@...> wrote: I would say that there are multiple levels of design, including architecture, systems design, security design, and so on. TDD isn¡¯t intended to help with those. It helps you get to clean code, based on the idea of elimination of duplication, good cohesion, and so on. That¡¯s a lower-level of design, but one of the most obvious when you¡¯re having trouble understanding and maintaining code.?
----------------- Author, HttpUnit <> and SimpleStub <> Now blogging at <>
Have you listened to Edict Zero <>? If not, you don¡¯t know what you¡¯re missing!
The original proposition, partly, as stated is:One can learn design skill by practising TDD, and I consider this a kind of pracitisng TDD "well"
I feel this falls into the trap of not being clear about what we meanwhen we say TDD.If one defines TDD as a process. Red, Green, Refactor.First write a failing test.Only write enough code to make the test pass.Etc...It seems to me that refactoring is the part of the TDD process wherewe "improve the design of the running, tested code without changingits functionality".How can we improve the design, unless we already know what constitutesgood design, and what constitutes bad design? TDD itself doesn't tellus, it is just a process. We must obtain the sensibilities of designelsewhere.I see one exception to this: design for testing. The act of trying towrite tests for code that is not designed for testing, using patternsthat we are familiar with that do not promote design for testing, willmake life painful. If we listen to our tests then we will try andremove this pain, and by doing so blunder randomly into patterns thatpromote design for testability.In all other ways however I cannot see how good design sensibilitiesare taught by the TDD process. They must be learned elsewhere.I concede that there are probably things I might not be considering.If someone has some proof of 'emergent properties of a simple system'that show good design emerges from repeated application of the TDDprocess without any external input (in terms of design), I would bemost interested.TDD at least fulfils the requirement of fast feedback for a Chaotic system.Fox---On Wed, 5 Jul 2023 at 10:12, Mauricio Aniche <mauricioaniche@...> wrote:
Hey, Charlie and Gregory,
Thanks for your message. Where did I get that from... This is a good question!
In the bubble of engineers I follow, I sometimes get the impression
that people believe that TDD is this thing that magically turns bad
code into good code. Or that the only way to achieve great design is
by doing TDD, if you don't, you'll produce crappy code. I disagree
with that, and I'm happy to see you also don't really see it this way.
I believe that, in order to make great design decisions, you need
input from many different points of view. Test code is one of them,
but certainly not the only nor the most effective one for all types of
design challenges. In many of the hardest design decisions I had to
take, my knowledge on OOD + lots of lessons learned and examples from
APIs I've read and developed in the past were the main drivers behind
my choices.
That being said, I see lots of advantages in the rhythm that TDD
brings, just like Gregory mentioned. TDD was the best teacher I could
ever have in terms of teaching me how to break something complex into
small bits, how to make sure I have tests to give me confidence, and
on how to focus on one thing at the time. Interestingly, one of my
favorite academic papers, by Fucci et al, conclude that " The claimed
benefits of TDD may not be due to its distinctive test-first dynamic,
but rather due to the fact that TDD-like processes encourage
fine-grained, steady steps that improve focus and flow." (in A
Dissection of the Test-Driven Development Process: Does It Really
Matter to Test-First or to Test-Last?)
Cheers,
--
Maur¨ªcio Aniche
Author of Effective Software Testing: A Developer's Guide
On Tue, Jul 4, 2023 at 10:43?PM Gregory Salvan <apieum@...> wrote:
Mauricio, I believe like you "TDD doesn't magically guide you to good design", because it's not magic, it's focus.
Do you agree that TDD in itself can be seen as a frame that ensure you to think about your design often and check its resilience step by step ?
When you?e practicing TDD, for each small step, during refactoring phase, you've to focus on your design and how to improve it, this is how it leads to become better at design imo.
In my case I've observed, that the more I became experienced, the less I was breaking tests when modifying my code and the less changes were expensives. It sounds like the high flexibility you're talking about.
|
Re: Which comes first: design skill or TDD?
Refactoring is an essential part of TDD, wouldn¡¯t you say? And how can you refactor if you cannot recognize code smells that indicate that the code is not clean?
toggle quoted message
Show quoted text
On Jul 5, 2023, at 1:39 PM, Sleepyfox <sleepyfox@...> wrote:
But TDD doesn't teach you about coupling and cohesion, it doesn't teach you about 'clean code' (whatever you determine that to mean), it doesn't even teach you about removal of duplication - that's Simple Design.
Fox On Wed, 5 Jul 2023, 17:27 Russell Gold, < russ@...> wrote: I would say that there are multiple levels of design, including architecture, systems design, security design, and so on. TDD isn¡¯t intended to help with those. It helps you get to ?clean code, based on the idea of elimination of duplication, good cohesion, and so on. That¡¯s a lower-level of design, but one of the most obvious when you¡¯re having trouble understanding and maintaining code.?
----------------- Author, HttpUnit <> and SimpleStub <> Now blogging at <>
Have you listened to Edict Zero <>? If not, you don¡¯t know what you¡¯re missing!
The original proposition, partly, as stated is:One can learn design skill by practising TDD, and I consider this a kind of pracitisng TDD "well"
I feel this falls into the trap of not being clear about what we meanwhen we say TDD.If one defines TDD as a process. Red, Green, Refactor.First write a failing test.Only write enough code to make the test pass.Etc...It seems to me that refactoring is the part of the TDD process wherewe "improve the design of the running, tested code without changingits functionality".How can we improve the design, unless we already know what constitutesgood design, and what constitutes bad design? TDD itself doesn't tellus, it is just a process. We must obtain the sensibilities of designelsewhere.I see one exception to this: design for testing. The act of trying towrite tests for code that is not designed for testing, using patternsthat we are familiar with that do not promote design for testing, willmake life painful. If we listen to our tests then we will try andremove this pain, and by doing so blunder randomly into patterns thatpromote design for testability.In all other ways however I cannot see how good design sensibilitiesare taught by the TDD process. They must be learned elsewhere.I concede that there are probably things I might not be considering.If someone has some proof of 'emergent properties of a simple system'that show good design emerges from repeated application of the TDDprocess without any external input (in terms of design), I would bemost interested.TDD at least fulfils the requirement of fast feedback for a Chaotic system.Fox---On Wed, 5 Jul 2023 at 10:12, Mauricio Aniche <mauricioaniche@...> wrote:
Hey, Charlie and Gregory,
Thanks for your message. Where did I get that from... This is a good question!
In the bubble of engineers I follow, I sometimes get the impression
that people believe that TDD is this thing that magically turns bad
code into good code. Or that the only way to achieve great design is
by doing TDD, if you don't, you'll produce crappy code. I disagree
with that, and I'm happy to see you also don't really see it this way.
I believe that, in order to make great design decisions, you need
input from many different points of view. Test code is one of them,
but certainly not the only nor the most effective one for all types of
design challenges. In many of the hardest design decisions I had to
take, my knowledge on OOD + lots of lessons learned and examples from
APIs I've read and developed in the past were the main drivers behind
my choices.
That being said, I see lots of advantages in the rhythm that TDD
brings, just like Gregory mentioned. TDD was the best teacher I could
ever have in terms of teaching me how to break something complex into
small bits, how to make sure I have tests to give me confidence, and
on how to focus on one thing at the time. Interestingly, one of my
favorite academic papers, by Fucci et al, conclude that " The claimed
benefits of TDD may not be due to its distinctive test-first dynamic,
but rather due to the fact that TDD-like processes encourage
fine-grained, steady steps that improve focus and flow." (in A
Dissection of the Test-Driven Development Process: Does It Really
Matter to Test-First or to Test-Last?)
Cheers,
--
Maur¨ªcio Aniche
Author of Effective Software Testing: A Developer's Guide
On Tue, Jul 4, 2023 at 10:43?PM Gregory Salvan <apieum@...> wrote:
Mauricio, I believe like you "TDD doesn't magically guide you to good design", because it's not magic, it's focus.
Do you agree that TDD in itself can be seen as a frame that ensure you to think about your design often and check its resilience step by step ?
When you?e practicing TDD, for each small step, during refactoring phase, you've to focus on your design and how to improve it, this is how it leads to become better at design imo.
In my case I've observed, that the more I became experienced, the less I was breaking tests when modifying my code and the less changes were expensives. It sounds like the high flexibility you're talking about.
|
Mark Levison
Jovche Mitrejchevski
Dan Torres
Gu?laugur Egilsson
Sleepyfox