Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Originally posted by Lasse Koskela:
Yes, I definitely think TDD helps me develop better software than the traditional test-after approach.
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Frank Carver:
As a known TDD-booster, Ilja, do you ever find yourself doing something like this?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Rahul Bhattacharjee:
Writing programs strictly to interfaces would enable you to write the test first.
Mary Poppendieck
Author of Lean Software Development, Implementing Lean Software Development, and Leading Lean Software Development
I'm writing a book on Test-Driven Development.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Ilja Preuss:
Jeanne, when you don't do TDD, does that mean that you
"write the code first, then write the test",
or do you fully skip the tests?
In my experience, writing tests for existing code is just so much harder that I can't think of it as a good alternative to TDD...
[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Originally posted by Frank Carver:
It could well be that when Jeanne talks of "writing a class that has the API set by our framework and is very short/simple", the code is actually written as if the tests are there, but the tests are never run because they don't actually exist.
Originally posted by Frank Carver:
Sure, this approach does not get the long-term benefits of TDD (catching typos and misunderstandings, a growing regression suite, executable documentation of how to use the code, etc.) but it still has some design value. If there can be said to be a "half-TDD" process, this might be it.
[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Originally posted by Jeanne Boyarsky:
No! Of course I don't skip the tests.
I guess I don't consider just writing the tests first to be TDD. The tests aren't driving much of anything if I already know what the completed product will look like.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Ilja Preuss:
even if I think I already know what it should look like.
[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
Originally posted by Jeanne Boyarsky:
There isn't a whole lot of variation in "return myForm.getInputId();"
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
You start by writing a test, then write the same test in the manuscript, then make the test pass as quickly as possible, then write the same implementation to the manuscript, then ...Originally posted by Stan James:
So now it's write the test first or the code first or the book first?
Originally posted by Stan James:
I wish I could properly attribute these three rules ... it was on ButUncleBob.com but not sure which author.
1) Write production code only to make a failing test pass
2) Write only enough test to make it fail
3) Write only enough production code to make the test pass
That's pretty explicit and extreme on write the test first. I think that would be very hard to do 100% of the time.
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Originally posted by Jeanne Boyarsky:
There isn't a whole lot of variation in "return myForm.getInputId();"
Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Originally posted by Lasse Koskela:
The need to write routine-like code is often a sign of duplication in the code base. Perhaps some of this stuff could be done dynamically, possibly using reflection?
[OCP 17 book] | [OCP 11 book] | [OCA 8 book] [OCP 8 book] [Practice tests book] [Blog] [JavaRanch FAQ] [How To Ask Questions] [Book Promos]
Other Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, TOGAF part 1 and part 2
And then the flying monkeys attacked. My only defense was this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
|