Cell Phone Software Forum
| View previous topic :: View next topic |
| Author |
Message |
Roy Smith
Guest
|
 Posted: Thu Apr 26, 2007 6:40 am Post subject: What to teach about TDD? |
 |
|
I'm thinking of giving a lunchtime talk to my development group on the
topic of how to write good unit tests, with a slant towards Test Driven
Development. My dilema is not what to include, but what to leave out.
These talks are typically 45-60 minutes followed by 15-30 minutes of Q&A.
That's not a lot of time, so the trick here will be figuring out what are
the really essential core topics that MUST be covered, and what can be left
out or glossed over. Any suggestions?
The primary audience is going to be C++ and Java developers (I do C++), but
I expect there will be some QA/QE people mixed listening as well. |
|
| Back to top |
|
 |
| |
Ads |
Advertising
Sponsor
|
|
Guest
|
| Posted: Thu Apr 26, 2007 9:38 am Post subject: Re: What to teach about TDD? |
|
|
"Roy Smith" <roy@panix.com> wrote in message
news:roy-A48ACB.22404425042007@032-325-625.area1.spcsdns.net...
| Quote: |
I'm thinking of giving a lunchtime talk to my development group on the
topic of how to write good unit tests, with a slant towards Test Driven
Development. My dilema is not what to include, but what to leave out.
These talks are typically 45-60 minutes followed by 15-30 minutes of Q&A.
That's not a lot of time, so the trick here will be figuring out what are
the really essential core topics that MUST be covered, and what can be left
out or glossed over. Any suggestions?
The primary audience is going to be C++ and Java developers (I do C++), but
I expect there will be some QA/QE people mixed listening as well.
Be sure to provide a balanced perspective. That is, point out the limitations |
of TDD as well as its benefits.
Richard Riehle |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Roy Smith
Guest
|
| Posted: Thu Apr 26, 2007 3:31 pm Post subject: Re: What to teach about TDD? |
|
|
<adaworks@sbcglobal.net> wrote:
| Quote: |
Be sure to provide a balanced perspective. That is, point out the
limitations of TDD as well as its benefits.
|
A reasonable suggestion. I've been around the block enough times to know
that everything has limitations, but I'm curious which specific ones you
think are worth mentioning in a 45 minute intro talk? |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Phlip
Guest
|
| Posted: Fri Apr 27, 2007 4:22 am Post subject: Re: What to teach about TDD? |
|
|
Roy Smith wrote:
| Quote: |
adaworks@sbcglobal.net> wrote:
Be sure to provide a balanced perspective. That is, point out the
limitations of TDD as well as its benefits.
A reasonable suggestion. I've been around the block enough times to know
that everything has limitations, but I'm curious which specific ones you
think are worth mentioning in a 45 minute intro talk?
|
An important concept here is "don't say that which you must then redact."
Don't say some soap gets dishes "spotless" if you must then say "virtually
spotless", to avoid a lawsuit over a single spot.
Don't mention benefits. Don't say "TDD prevents bugs" if you must then say,
"If you also frequently iterate and constantly deploy and constantly review"
etc. etc. That allows you to avoid mentioning the limitations, so neither
topic will waste time. Just get to "write simple tests, then write simple
code to pass them, then refactor under test, and repeat until done".
If anyone asks what the benefits are, just say "TDD produces code that
strongly resists bugs".
--
Phlip
http://flea.sourceforge.net/PiglegToo_1.html |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Guest
|
| Posted: Fri Apr 27, 2007 10:01 pm Post subject: Re: What to teach about TDD? |
|
|
"Roy Smith" <roy@panix.com> wrote in message
news:roy-981EB3.07314726042007@032-325-625.area1.spcsdns.net...
| Quote: |
adaworks@sbcglobal.net> wrote:
Be sure to provide a balanced perspective. That is, point out the
limitations of TDD as well as its benefits.
A reasonable suggestion. I've been around the block enough times to know
that everything has limitations, but I'm curious which specific ones you
think are worth mentioning in a 45 minute intro talk?
Someone once noted that "every political system contains the seeds of |
its own destruction." This is also true of good ideas. As you note,
every good idea also has its limitations. Another way of saying that
is that every new set of solutions introduces a new set of problems.
TDD does have a lot to offer as one facet of the software evaluation process.
However, by itself, it is not sufficient.
One of the most important tasks in any engineering process is failure analysis.
The software evaluation activity has the goal of failure prevention, as much as
product feature success. TDD can test for product features, but it falls short
of dealing with failure prevention.
Every engineered product, whether software or physical, has places where failure
can occur, often as a natural consequence of the design. Failures occur for
many
reasons. A central cause of failure is related to the interaction of the
components,
not to their individual defects. Therefore, we must identify potential points
of
failure in the design, and incorporate controls to mitigate the effect of an
identified
stress point, or prevent those failures from occurring at all.
A child, stacking one block on top of another, is working with perfectly good
blocks.
They are small cubes, usually flat enough to allow the stacking of four or five
without
much difficulty. Once the stack gets as high as ten blocks we notice an
increase in
instability. There is nothing intellectually incorrect in the child's
reasoning about the
stacking of blocks. He ought to be able to stack them twenty feet high. His
initial
test of five blocks indicates that this is so.
In software, a system with a few features, or a few components, is easy to test,
and
the relationships between those components will seem to forecast that we can
easily
add more without much trouble. We can test these as we go. After several
tests,
we may conclude that the entire production is stable and pronounce it "Good."
However, there may continue to stress points in the design that have not
revealed
themselves in any of the series of tests we have concocted. The more complex
the design, the more probable it becomes that those stress points are activated.
TDD is a perfectly good idea, but an incomplete idea. It is naive for anyone to
think that this practice will ensure the absence of failure in the final
software
product. Yet it is foolish for anyone to decide that, because it does not
detect
every kind of potential failure, that is not important. TDD is a tool. We
need
multiple tools for the evaluation of a software system, but this tool can be
effective as one part of that evaluaton process.
Richard Riehle |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
208 Attacks blocked
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
