For Programmers: Free Programming Magazines  


Home > Archive > Extreme Programming > May 2005 > Unit testing editors and text processors









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Unit testing editors and text processors
Steve Jorgensen

2005-05-16, 8:56 am

A while back, I ran a team that was working on an Open Source project, working
in an XP way. The product was expected to parse and generate VB source code.

In many cases, the simplest tests we could come up with still needed to parse
and/or generate some fairly large blocks of text that were not practical to
insert into the test code itself. As a result of this, we ended up putting
the test input and output data into database tables instead. This was working
OK, but it had all of the problems you'd expect from not having the test data
and code together in one place.

As it happens, I may be working on another project soon with similar issues, a
specialized text editor. Any advice on how to best think about writing unit
tests for this type of code?

Thanks,

Steve J.
Robert C. Martin

2005-05-16, 8:57 pm

On Sun, 15 May 2005 23:10:00 -0700, Steve Jorgensen
<nospam@nospam.nospam> wrote:

>A while back, I ran a team that was working on an Open Source project, working
>in an XP way. The product was expected to parse and generate VB source code.
>
>In many cases, the simplest tests we could come up with still needed to parse
>and/or generate some fairly large blocks of text that were not practical to
>insert into the test code itself. As a result of this, we ended up putting
>the test input and output data into database tables instead. This was working
>OK, but it had all of the problems you'd expect from not having the test data
>and code together in one place.
>
>As it happens, I may be working on another project soon with similar issues, a
>specialized text editor. Any advice on how to best think about writing unit
>tests for this type of code?


Some folks use a scheme called an Object Mother. If you do a google
search I think you can find a writeup. It's just a class that builds
pre-configured test data for you.


-----
Robert C. Martin (Uncle Bob) | email: unclebob@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716


"The aim of science is not to open the door to infinite wisdom,
but to set a limit to infinite error."
-- Bertolt Brecht, Life of Galileo
jeffgrigg@charter.net

2005-05-17, 3:57 pm

Some people store text files in the same directory as the source files.
(And these non-programming-language files don't have to just be plain
text.)

Alternately, you /can/ put lots of text into your source code, if
you're somewhat creative. Here's a Java example:

final String[] testLines = new String[] {
"Line 1",
"Line 2",
"Line 3",
// ... //
"Line N",
};

Phlip

2005-05-17, 8:57 pm

jeffgrigg wrote:

> Some people store text files in the same directory as the source files.
> (And these non-programming-language files don't have to just be plain
> text.)


Retrofitting tests lead to "characterization tests" (per Mike F.'s Legacy
Code book) that tend to fill up with large amounts of captured data, for
comparison.

I once added tests by adding module_test.cpp to each module.cpp, in the same
folder, and I tossed the test data into a sub-folder named testData. The
name was the same everywhere.

--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]


Steve Jorgensen

2005-05-18, 3:59 am

On Sun, 15 May 2005 23:10:00 -0700, Steve Jorgensen <nospam@nospam.nospam>
wrote:

>A while back, I ran a team that was working on an Open Source project, working
>in an XP way. The product was expected to parse and generate VB source code.
>
>In many cases, the simplest tests we could come up with still needed to parse
>and/or generate some fairly large blocks of text that were not practical to
>insert into the test code itself. As a result of this, we ended up putting
>the test input and output data into database tables instead. This was working
>OK, but it had all of the problems you'd expect from not having the test data
>and code together in one place.
>
>As it happens, I may be working on another project soon with similar issues, a
>specialized text editor. Any advice on how to best think about writing unit
>tests for this type of code?

....

Thanks to all who responded. It took me a bit of work to understand what
Object Mother is all about, but I think I see how it's a good way to deal with
the situations I'm describing.
Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com