Hi everyone,
currently I got interesting more and more in XP and are wondering about
whether it might suite my needs. I am developing some heavy calculation
software in the computer graphics domain. It takes some points and
creates the triangles of the surface. So the highest value to the user
is:

1) Create a surface out of the given points.
2) Do it as fast as possible.
3) It would be nice if the surface looks good.

And here the problem starts. Xp states that I should use TDD. In may
case it would be a check whether the surface is consistent. Still this
is by far not enough see whether it is a valid triangulation or even
judge the quality of the constructed surface. If a test could be
written, then I guess it would be a good metric to design the algorithm
in hole.

I have no idea how to start breaking down the tests to let them appear
meaningful. E.g. I test whether each point is used by at least x
triangles or whether each triangle is between neighboring points but
all test might say the reconstruction is ok but the mesh might be not
valid at all. Currently I am applying the algorithm on about 100 test
data sets manually and check the result piece by piece, which is an
extremely tedious work that needs the whole day. So what would an XP
Expert do in such a situation?

BTW: Does design by contract make unit test superfluous? (At least in
this domain?)

Thanks in advance,
Thomas Kowalski

th-ko wrote:


Do you need high transparency, trust, and accountability?

http://developers.slashdot.org:80/a...6/09/19/0520252


One Tom Plunket did that for one of his first Test Driven Development
situations. I CC'd him.


Before we go further, understand that Software Development has two cycles.
The outer cycle is feature requests and releases, and the inner cycle is
TDD - tests and code to pass the tests.

When you prioritize features, the user's liaison - the Onsite Customer -
declares a feature to be high or low value. So we will assume your customer
needs triangle mesh simplification.

Within the inner cycle, the next TDD test to write is the test for the
simplest code ability of the highest risk feature. So to start, you would
draw the Triangle Simplification user story card over a lower risk one, such
as "sort the contents of that list box". Leave the dumb easy stuff for
last - within an iteration.

Within the Triangle Simplification task, you would pick the simplest kind of
triangle, simplify it, and repeat for the next more complex kind of
triangle.


TDD creates "unit" tests, where "unit" just means "low level, and targeting
one small code region". (There are QA definitions of Unit Test that needn't
concern us".

You describe an "acceptance test". That's a high-level test which generally
demonstrates the code matches its requirements.


If you were to implement the triangle problem, using a known algorithm,
what's the first few lines of code you would write? I would bet they
wouldn't be triangular. They might even be a low-level function, such as
"find the normal", or even lower, "find the normal for a degenerate
situation".


That's because you started top-down. Start hard algorithms bottom-up. Look
up your algorithm in a graphics book, and sketch on paper the calculation
for the simplest instance of that algorithm. I don't know the problem
myself, so I guess there could be a situation even simpler than taking 4
regular triangles, stuck together to form a bigger regular triangle, and
simplifying out the triangle in the middle.

Then repeat for a slightly harder situation. Move one point so the triangles
are not regular. And so on.


That is QA testing. TDD is about thinking about the next line of code you
intend to write, and then writing it first inside-out, as a failing test.


Write a simpler algorithm - such as reversing a string, or converting an
integer into Roman Numerals - before diving into implementing a hard
algorithm.


DbC is a competing theory and a complementing system. However, you also
can't write a contract first and then write code to pass the contract. (You
trivially can. But TDD is also about designing by writing more failing tests
and passing them, and you can generally only fail a contract once!

I have not heard that DbC users experience the rapid velocity, high
flexibility, and low bug rate that TDD addicts report. I suspect they get a
super-low bug rate at the expense of low velocity and low flexibility. But I
could be Ron.

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

Hi Phlip,

Actually triangulation of objects or surface reconstruction. But that
is secondary...

simplest code ability = the smallest working chunk of code for a small
part of the algorithm.
highest risk = the most difficult to achieve.


Or one the the next iterations, right?


Solve the smallest possible problem and then extend it. If it reaches a
level that satisfy the QA then care for the next detail, correct?


Ok, that is exactly my problem. I can't identify _meaningful_ unit
tests. The tests I can manage have not more value then testing whether
1 is really 1 . How to create "good" unit tests? What about code
coverage? How can it be determined?
To be more precise: I might test for example whether the next
neighboring point p of a point q is really the next point from a given
set. But the meaning for the algorithm or even method might rather
small. Are this fractions of unit tests ever combined to bigger unit
tests? If yes, how?


If this is not automated its still ok for XP?

Ok. I get a lot of tiny parts. And in the end of this process a this
tiny test are clustered to bigger test?

Isn't the basic idea of both to test the code for things that might go
wrong?


I don't really understand what you mean here. If a unit test fails I
rewrite the code to make it pass. If a contract fails I do the same,
start the software and test whether the contract fails again. I guess
you can even automate it to a certain degree.

Thanks a lot for your helpful answer,
Thomas Kowalski

th-ko wrote:


Nope. From the top:

- the Onsite Customer selects stories
- developers estimate them
- the Onsite Customer cuts one short stack
for this week
- developer do the high-estimate ones first

Before the developers run out of time (typically before one week), they get
around to low-estimate ones. These are still equal priority with the
high-estimate ones.

An iteration should end with as many stories completely done as possible.
90% of the stories 100% done is better than 100% of the stories 90% done.

So the team has no option and little incentive to boot the low-estimate
stories out of this iteration. By Thursday the team should recognize which
stories cannot be finished, and should boot _those_. Then they should take
care of all the low-estimate stories.

This is similar to how to do a math exam. Go thru once looking for anything
you can easily knock out. Then go back and do all the intermediate
questions. Then go back and apply soak time to the hard ones. Then go back
and re-check everything.

Actually, it's the opposite of how to do a math exam. A teacher would give
90% credit either way, whether you finished hard ones or easy ones. An
Onsite Customer will not. Do the hard ones first, boot out the hardest ones,
and spend the remaining time finishing up the easy ones.


"QA" means the Customer Team members who write acceptance tests. We are only
talking about development and unit tests from now on.

Solve the simplest problem of the current user story first. If the user
story says "invent a language", then write a test for 'print "hello world"'
first. Pass the test, then add integers, operators, and so on.


If you were going to write the first line of code, what would it be?

(You might also write this program in a sandbox, without TDD. Then take what
you learned and write it all again with TDD creating each line.)


Yes: You write a purely stupid test that _only_ checks that one point is the
neighbor. For example:

points = [[2,2,2], [3,6,1], [5,9,8]]
nearest = getIndexOfNearestPoint([1,1,1], points)
assert_equal 0, nearest

That's all: Just a test you could pass blindfolded. You could even hard-code
'return 0' inside the function.


By using the unit tests to force your lies in the code to go away. Here's
the next test:

points = [[3,6,1], [2,2,2], [5,9,8]]
nearest = getIndexOfNearestPoint([1,1,1], points)
assert_equal 1, nearest

Careful inspection of that source should reveal simply cloned and modified
the last test case to create this one. That is a perfectly valid technique.
But now my new test forces me to change the source of
getIndexOfNearestPoint(). It must now actually have some logic. So I replace
the contents with the _simplest_ logic that

Keep going like this, and the contents of the function will grow.

(And read either of the books called /Test Driven Development/.)


Nope. For XP, the outer cycle around TDD, your team should respect such
tests, and should automate any kind of test they can possibly automate, if
they all agree to its quality and relevance. No code should be untestable.


TDD is also a design technique. DbC can't start simple and grow. (It can,
and when it does it's just TDD, not really DbC!)


You can't run sample data thru the contract and get results. So you can't
use the contract to force the designs to grow.

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

Phlip wrote:

I'm just going to chime in here. Thomas, as the program becomes
more complex, people tend to break or find defects in "the
obvious stuff" they did before, as they write more code that
uses those functions. The unit tests catch the problems while
they are small problems rather than letting them grow larger.

Godzilla is easier to deal with if you catch him while he's
still a baby lizard.

So, as Phlip said, yes, you really do write simple little
tests.