Re: Test Tools

Sav wrote:

"test-first" is good. Google for it, with the quotes.

"test-last" means writing the code first, then writing the tests. It's
bad.
And everyone does it.

Oh! Extreme programming guys seems to be proponent to this practice.
Interesting,
but I'm not really sure if that works in practice -- anyone here had
good experience
with such test-first plan?

I know of only one person who reported less than spectacular success (rapid
development with a super-low bug rate) when they tried TDD on an
experimental project.

That person is Mike Bolton. The two things I suspect he did wrong were A>
write high-level unit tests instead of short brainless tests that are _easy_
to game, and B> going in very large steps instead of very small steps.

One should only write a few lines of test code before answering them with a
few lines of production code.

However, I brought up "test last" to distinguish it from "developer-centric
testing". That just means developers write their tests within the same
iteration as their tested code.

...Let me present my ... theory...

From "http://www.xprogramming.com/xpmag/testFirstGuidelines.htm";, a
test-first
process would be something like this:

[1] The name of the test should describe the requirement of the code

TDD works for Acceptance Tests and Unit Tests. At the Acceptance level, the
programmer should collaborate with a customer liaison to express
requirements as tests. These should have names that fit the project's System
Metaphor, so the customer will learn to understand their jargon.

However, at the Unit level, the meaning of a test case could change as you
write the code to pass it! So describing the requirements is a good goal,
but not a fixed rule.

[2] There should be at least one test for each requirement of the code.

At the acceptance test level, yes. If you can't write such a test, then your
code is not refactored cleanly enough to expose all its behaviors. So keep
trying, even if "analysis" reveals some features are not test-worthy.

Each possible path through of the code is a different requirement

At the Unit Test level, you shouldn't write any line of code, including 'if'
statements, without a failing test requiring it. So TDD will approach this
goal, and we Test Engineers can then work to ensure the tests cover more
paths.

[3] Only write the simplest possible code to get the test to pass, if
you know this code to be incomplete, write another test that
demonstrates what else the code needs to do

Right. If you can only test that function Foo() returns 42, then your first
version of Foo() should be int Foo() { return 42; }. As further tests
require more abilities of Foo(), then you put more creative contents inside
it.

This technique - challenging clever tests with stupid code - forces the
tests to cover all abilities.

[4] A test should be similar to sample code, in that it should be clear
to someone unfamiliar with the code as to how the code is intended to
be used

Right - polish the tests so they document the tested code.

The test cases relevance are really high. From the tester point of view
its really great to have these work done but I'm really not sure if
the
development team would be happy with that. It's so boring to write a
test case for each requirement.

Debugging is boring. Delivering useless features to customers is boring.

TDD is challenging, because you write the question first, before the answer.
It's like a riddle.

I'm considering all the human factors here

Developers familiar with Debugger-Driven Development are typically sick of a
feature by the time it works. So they may resist the idea of _then_ writing
test cases. That would be boring!

TDD is exciting. You have much better visibility, so you can go faster.

-- perhaps we are going
through an 'industrial revolution' in TI;

Yep.

all that matter is the
product
and the company. Where did the art go?

You mean where did all the late-night coding, hair-pulling, drug-abusing,
capital-risking go?

Projects still have risks. We think we have a better control on them; better
awareness of them.

This procedure changes
a lot the way the programmer does his job, and therefore, the way
he _thinks_. The programmer now is jailed in this mechanic
process.

After you learn it, you start thinking in terms of tests that will pull your
code along. I heard a good metaphor yesterday that I should pass along.

In the "Star Trek" cosmology, all starships have transporters that beam down
away-teams. When the transportation part is instant and safe (within the
needs of the plot), the Captain doesn't need to beam down a complete crew of
specialists. The Captain can beam down a science officer and a tactical
officer, to check things out. When this crew encounters challenging geology
or biology, they can request to beam down specialists in exogeology and
exobiology.

That is "adaptive planning". You collect feedback from an environment, and
you plan for all contingencies by committing your forces only when feedback
discovers a real need.

So, we still have to do good tests; how? From my humble (honestly,
I'm new in software engineering) point of view, there must be a middle
point of equanimity. I completely disagree with these extreming
programming steps, cause they are extreme; they don't consider the
human factor. It leads to a boring job. I'd have to think deeper about
a
possible way out, can someone contribute with some thoughts? :-)

There will always be a pro-tester role. For example, someone must help the
"onsite customer" author acceptance tests. And someone must maintain the
test servers, polish and distribute their results, and collect their
metrics.

Back to the previous topic, and realting to my trolling speach, I'll
try
a new method of test-first. I'm charged of managing the quality of
a software in my company, but I'm still thinking how I'm going to do
that.

Find a developer who has heard of it (maybe the guy with the most books in
his cube), and ask him or her to experiment with it.

--
Phlip
http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!!!


.

Relevant Pages

  • Re: Programming Languages, "to C or not to C, that is the Q."
    ... Your extreme example serves to show that clarity is dependent on the ... It is not the language that needs to be clear, ... clarity is all on the programmer. ... > Extreme cases, to be sure, and yet Perl has such a lovely thing as this ...
    (Debian-User)
  • Re: A quick newbie question on TOP.
    ... lose your job to a more 'pragmatic' programmer. ... Well, the Pragmatic Programmers are totally behind TDD, and they are ... Could it be because they are open-source, ... A year from now, when the customer asks for a new feature, you ...
    (comp.object)
  • Re: TDD and private classes/usercontrols
    ... So whether a programmer formally states the Business ... But I didn't think TDD is supposed to identify this kind of stuff. ... paralleling tdd (okay unit testing) and the compiler ... but it is definitely NOT rubbish. ...
    (microsoft.public.vb.general.discussion)
  • Re: The Override Problem
    ... Andrew McDonagh wrote or quoted: ... > Any (Java) programmer who can't TDD will soon find their resumes ...
    (comp.lang.java.programmer)
  • Re: CreateProcess in a loop
    ... and I'm more extreme than a lot of MFC example code. ... programmer would write. ... At one time char was important and represented state-of-the-art, ... Books I have are introduction to MFC which is not ...
    (microsoft.public.vc.mfc)