开云体育

There are two schools on writing tests to force you to replace "10" with
"amount * rate".

The first school I call Triangulation. It predicts that you wait until you
are converting 10 USD at 2:1 and 20 USD at 3:1 before you can have both
variables in the target statement. I do not generally subscribe to this
school, although I can do it if necessary.

The second alternative is FITYMI (Fake it til you make it). This says that
you first create a constant response, then refactor to eliminate duplication
between test case and code.

I've tried Triangulation, but the steps don't seem valuable to me, so I
quickly lose motivation. When using FITYMI I occasionally slip into
premature abstraction, but generally I'm much happier with the steps.

The third alternative is, I suppose, just typing in the correct
implementation from the get go, variables and loops and all. This is kind of
third gear, and is probably what I really do most of the time.

Kent

There are two schools on writing tests to force you to
replace "10" with
"amount * rate".

Lately we used "negative tests" to drive the code from
constants to calculation.

starting with an assert and a constant implementation
we write a second assert that shows how the code is
expected to fail.

It gives very much the impression of "code massage".
I like that picture. It's like bending in two directions.
In german we came to the idiom "den code durchkneten"
(to kneat).

cheers
Mittie

"Lately we used "negative tests" to drive the code from
constants to calculation.

starting with an assert and a constant implementation
we write a second assert that shows how the code is
expected to fail.

It gives very much the impression of "code massage".
I like that picture. It's like bending in two directions.
In german we came to the idiom "den code durchkneten"
(to kneat)."

Please tell me if this is covered in the Triangulate pattern. I've done
this, too, but it drives me nuts. This could easily be a flaw in my
technique.

Kent

The "negative" tests seem to be a variation or a special
instance of the Triangulate pattern. I guess I have to give an
example.
The example is how CanooWebTest does selftesting by applying it to
itself. What we have to test is, that our verification of web pages
works as expected.
From
follow the link to "Latest Results of Functional SelfTest". That is
the test report (created by the CruiseControl).
Test No 4 makes a good example for trying to invoke a page and verify
it somehow. Then a *negative* test follows to show how verification
is expected to fail. (It is wrapped in a NOT, which is like
assertFalse() in unit tests)

The special thing here is, that positive and negative tests are not
redundant as opposed to the example about Triangulation.

The FITYMI impl of page verification can just return true as long as
you have the positive test only. The negative test finally enforces
the logic.

I experienced quite a nice effect with this: there is (almost) always
one test breaking and the other working until I'm finished. The
information of which on is currently breaking gives good guidance
while proceeding from FITYMI to full implementation. Really good
honest feedback without trying to fool myself. When tests are green,
I'm _really_ finished.

BTW: I don't fully understand the word "Triangulation" maybe because
it has no one-to-one translation into german. Is it that the
two asserts and the production code make up a triangle?
What am I supposed to do with that triangle? Calculate the
third point (production code) by knowing the remaing two?
Then I need some more information (lengths, circumference, angles...)
I need some more guidance to understand the anology.

cheers
Mittie

"Lately we used "negative tests" to drive the code from
constants to calculation.

starting with an assert and a constant implementation
we write a second assert that shows how the code is
expected to fail.

---

Please tell me if this is covered in the Triangulate pattern. I've

done

this, too, but it drives me nuts. This could easily be a flaw in my
technique.

---

Triangulation is the process of finding a remote point by getting the angle
to it from two points with known distance and orientation, and then doing
that sin/cos/tangent stuff. A little picture would go a long way towards
illustrating the concept.

I have no problem with writing a positive and a negative test. However, I
still refactor after the positive test, eliminating duplication between test
case and piggy implementation, before I write the negative test. I can
easily believe this is just a bad habit, and I can less easily believe this
is a technique I and only I among all the programmers of the earth can use
safely.

Kent

I can less easily
believe this
is a technique I and only I among all the programmers of the earth can use
safely.

I support your point.

I assume you're not a kind of programmer that would follow a directive
word-by-word. Neither do I.
Chances are: nobody does, really.

If forced to do so, we say goodbye.

When designing the little steps in TDD we have to take into account that
it is not a processor who is going to execute it. It's a programmer.
Maybe we loose the properties of completeness and logical correctness.
- so what.

"Extra test", Triangulation and negative test aim at completeness so that
an automaton could do it.

"Do I have to shut off my brain in order to do TDD?"

"No, but give your mind more freedom to learn and be creative by
having less in your "RAM"."

just some thoughts, no real point here...
Mittie