Extreme Programming - Using xUnit for test driven development

Author

Using xUnit for test driven development

Jeffrey Spoon

2006-10-30, 7:07 pm

Hello, I have some general questions about using xUnit, such as JUnit
when developing small projects. I plan to use this tool to develop a
small project I'm doing on my own. I like the idea of running a test rig
to gradually develop the software, rather than discovering a million
bugs during testing at the end of the cycle.

My question is, what actual tests do you run with the xUnit utility, are
they general scenario based tests, such as use cases, or deeper out of
bounds/input validation type tests that are usually carried out.

The reason I ask is because obviously I don't want to run a test rig
that doesn't really test the software adequately.

--
Jeffrey Spoon

Phlip

2006-10-30, 7:07 pm

Jeffrey Spoon wrote:

> My question is, what actual tests do you run with the xUnit utility, are
> they general scenario based tests, such as use cases, or deeper out of
> bounds/input validation type tests that are usually carried out.

What have you read about "Test-Driven Development"?

You should write tests for each new line (or two) of the code. Never write
new code without a failing test.

Because your software has scenarios, your top-level functions need tests
that they drive the scenarios properly. (Otherwise they will drive nothing!)
So you need scenario level tests.

Your low-level code needs to deflect and reject bad input. More lines of
code, so they need tests.

--
Phlip
[url]http://www.greencheese.us/Z

Land[/url] <-- NOT a blog!!!

Jeffrey Spoon

2006-10-30, 7:07 pm

In message <YQo1h.25363$7I1.12439@newssvr27.news.prodigy.net>, Phlip
<phlipcpp@yahoo.com> writes
>Jeffrey Spoon wrote:
>
>
>What have you read about "Test-Driven Development"?

Not a lot, I have to admit. Just odd articles on the web etc. All I know
is that you build a test rig, make sure your test fails on it's own,
then run them against your software. Repeat as you add more
functionality to your code. I was under the impression it was part of
XP.

>
>You should write tests for each new line (or two) of the code. Never write
>new code without a failing test.
>
>Because your software has scenarios, your top-level functions need tests
>that they drive the scenarios properly. (Otherwise they will drive nothing!)
>So you need scenario level tests.
>
>Your low-level code needs to deflect and reject bad input. More lines of
>code, so they need tests.
>

Interesting, thanks. I didn't realise it was as deep as that (i.e. every
couple of lines of code). I thought there might be higher level tests
for scenarios, and then for lower level stuff, as you mention. It
certainly seems to be a sensible way of avoiding big problems later on,
despite the initial work involved.

If you have any pointers to more information on it I'd be happy to have
a look.

Thanks,

--
Jeffrey Spoon

Phlip

2006-10-30, 7:07 pm

Jeffrey Spoon wrote:

> Interesting, thanks. I didn't realise it was as deep as that (i.e. every
> couple of lines of code). I thought there might be higher level tests for
> scenarios, and then for lower level stuff, as you mention. It certainly
> seems to be a sensible way of avoiding big problems later on, despite the
> initial work involved.

You are currently reading sites written by people who assume you know the
inner cycle, and they don't want to repeat explaining that cycle.

Here is a simple way to describe the inner cycle: "Run all the tests after
every few edits, successfully predict the result of each run, frequently
return to a Green Bar state, and use Undo if you predict wrong or can't
return".

To learn to do that, you should chant a mantra in your head; Test, Code, and
Refactor. But it's not the chant that's doing it; it's that tight cycle of
small changes and successful test runs. That prevents debugging.

Next, to put this system to use on a project, you write _another_ suite of
high-level tests, at least one for each user story (a line-item of a
feature). These tests should be easy to read, not source code. Start at
http://fitnesse.org

> If you have any pointers to more information on it I'd be happy to have a
> look.

Good lord.

Google for "CodeUnitTestFirst".

Then read any book with "Test-Driven Development" in its name.

Or read this, straight thru:

http://flea.sourceforge.net/TDD_in_a_nut_shell.pdf

--
Phlip
[url]http://www.greencheese.us/Z

Land[/url] <-- NOT a blog!!!

Jeffrey Spoon

2006-10-30, 7:07 pm

In message <_Fp1h.17952$TV3.4930@newssvr21.news.prodigy.com>, Phlip
<phlipcpp@yahoo.com> writes
>
>Next, to put this system to use on a project, you write _another_ suite of
>high-level tests, at least one for each user story (a line-item of a
>feature). These tests should be easy to read, not source code. Start at
>http://fitnesse.org
>
>
>Good lord.
>
>Google for "CodeUnitTestFirst".
>
>Then read any book with "Test-Driven Development" in its name.
>
>Or read this, straight thru:
>
>http://flea.sourceforge.net/TDD_in_a_nut_shell.pdf
>

Thanks Phlip, I'll have a look at these.

--
Jeffrey Spoon

Sponsored Links