How to structure a program for unit testing 
Author Message
 How to structure a program for unit testing

The time has come. I'm tired of that unsure feeling when I'm about to
release a program. So I've decided to jump on the unit testing band-wagon.
Trouble is, the wagon is going a little fast for me, and I'm kinda'{*filter*}
off the back end of it.

My Ruby programs seem to be one monolithic source file (~500 lines or so).
With classes defined, global functions, and, uhm, a global variable or two.
Problem is, I have functions that do a whole lot. They might open a file or
two, massage the data, and put it back into another file.

Is it possible to devise unit tests for programs structured like this?
Should I break my program into more source files?
Should I have a lot of smaller functions that do what the large function
does? This seems more susceptible to bugs, since you're throwing more data
around between functions.
When doing tests on file massagers, do you have a set of input files that
you use for the tests, and that remain with the tests, ie. TC_Massager would
use tc_label.txt and tc_format.txt?
Is it okay that the unit test functions are so closely coupled to the
classes, methods, etc.? (It would seem so, since everyone is so gaga over it
:-))

Thanks in advance, your brillantnesses, I know this is a lot to ask.
Feel free to tell me to RTFM, just provide a link to it :-)

--
Regards,
  JJ

Finally using a Mac!



Fri, 18 Nov 2005 19:24:00 GMT  
 How to structure a program for unit testing

Quote:

> My Ruby programs seem to be one monolithic source file (~500 lines or so).
> With classes defined, global functions, and, uhm, a global variable or two.
> Problem is, I have functions that do a whole lot. They might open a file or
> two, massage the data, and put it back into another file.

my ruby files is about 250 lines.

Quote:
> Is it possible to devise unit tests for programs structured like this?

No, you will have to isolate those things you want to do internal testing.
Yes, you can do external testing.

Quote:
> Should I break my program into more source files?

Yes.

1) I have a class containing many methods (more than 40).

2) I find out which methods whos related to eachother and move
   them out from the class into a standalone module.

3) Now you have 10 files and your main class looks like this:
   class Main
       include MainModuleA
       include MainModuleB
       include MainModuleC
   end

Now I want to write unittest for MainModuleA, i do like:
   class FakeMain
       include MainModuleA
       # overload methods that MainModuleA depends on
   end

   class TestBufferVert < RUNIT::TestCase
       def test_behavier
           i = FakeMain.new
           res = i.dostuff
           assert_equal("42", res)
       end
   end

Remember to write unittest before implementation :-)

Quote:
> Feel free to tell me to RTFM, just provide a link to it :-)

I know no manual I can point you to..
maybe read about aspect oriented programming (AOP).

--
Simon Strandgaard



Fri, 18 Nov 2005 19:56:09 GMT  
 How to structure a program for unit testing


Quote:
> If you are not familiar with the "test-first" approach, there are a
> number of writeups on any of the web sites devoted to XP (Extreme
> Programming).

There's also a nice translation of the "pink book" test-first
walkthrough in Ruby: http://www.rubycentral.com/articles/pink/

Regards,

Bill



Fri, 18 Nov 2005 20:59:35 GMT  
 How to structure a program for unit testing

Quote:

> Is it possible to devise unit tests for programs structured like this?
> Should I break my program into more source files?
> Should I have a lot of smaller functions that do what the large function
> does? This seems more susceptible to bugs, since you're throwing more data
> around between functions.

Others have already given you good advice about unit testing itself, and
so I thought I'd throw in my two cents on this part of your question.
You might want to check out Martin Fowler's book "Refactoring" for
strategies on how to restructure your code to improve its readability,
maintainability and testability.


Fri, 18 Nov 2005 22:34:48 GMT  
 How to structure a program for unit testing
The Kent Beck book Test Driven Development: By Example explains this in
great detail (and uses python and Java for code examples.)

Peter

Quote:
-----Original Message-----

Sent: Monday, June 02, 2003 7:24 AM

Subject: How to structure a program for unit testing

The time has come. I'm tired of that unsure feeling when I'm about to
release a program. So I've decided to jump on the unit testing band-wagon.
Trouble is, the wagon is going a little fast for me, and I'm kinda'{*filter*}
off the back end of it.

My Ruby programs seem to be one monolithic source file (~500 lines or so).
With classes defined, global functions, and, uhm, a global variable or two.
Problem is, I have functions that do a whole lot. They might open a file or
two, massage the data, and put it back into another file.

Is it possible to devise unit tests for programs structured like this?
Should I break my program into more source files? Should I have a lot of
smaller functions that do what the large function does? This seems more
susceptible to bugs, since you're throwing more data around between
functions. When doing tests on file massagers, do you have a set of input
files that you use for the tests, and that remain with the tests, ie.
TC_Massager would use tc_label.txt and tc_format.txt? Is it okay that the
unit test functions are so closely coupled to the classes, methods, etc.?
(It would seem so, since everyone is so gaga over it
:-))

Thanks in advance, your brillantnesses, I know this is a lot to ask. Feel
free to tell me to RTFM, just provide a link to it :-)

--
Regards,
  JJ

Finally using a Mac!



Fri, 18 Nov 2005 23:36:00 GMT  
 How to structure a program for unit testing

[snip]

Quote:
> If you are not familiar with the "test-first" approach, there are a
> number of writeups on any of the web sites devoted to XP (Extreme
> Programming).

Jim, I wanted to point OP to your excellent article at:

http://members.nuvox.net/~on.jweirich/talks/tdddemo/

but looks like it is not yet moved to your new website.
Or did I miss it ?



Sat, 19 Nov 2005 09:06:43 GMT  
 How to structure a program for unit testing

Quote:


> [snip]

> > If you are not familiar with the "test-first" approach, there are a
> > number of writeups on any of the web sites devoted to XP (Extreme
> > Programming).

> Jim, I wanted to point OP to your excellent article at:

> http://members.nuvox.net/~on.jweirich/talks/tdddemo/

> but looks like it is not yet moved to your new website.
> Or did I miss it ?

No it hadn't been moved yet.  I've moved off of the Nuvox (nee OneNet)
servers to my own server, but not everything is there yet.  I just
uploaded the Test Driven Developement Demo and you can find it at ...

    http://onestepback.org/articles/tdddemo/

I'm moving the other material on my site to the new location as I get
time.

--

---------------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)



Sat, 19 Nov 2005 10:23:23 GMT  
 How to structure a program for unit testing

Quote:

> No it hadn't been moved yet.  I've moved off of the Nuvox (nee OneNet)
> servers to my own server, but not everything is there yet.  I just
> uploaded the Test Driven Developement Demo and you can find it at ...

>     http://onestepback.org/articles/tdddemo/

Aha! Great  ... I always refer to it from time to time. Haven't yet mastered
the skill of  "test first".

Quote:
> I'm moving the other material on my site to the new location as I get
> time.

No sweat .. take it easy  !
Thanks a bunch.
-- shanko


Sat, 19 Nov 2005 20:52:17 GMT  
 How to structure a program for unit testing

Quote:


> > The time has come. I'm tired of that unsure feeling when I'm about to
> > release a program. So I've decided to jump on the unit testing band-wagon.
> > Trouble is, the wagon is going a little fast for me, and I'm kinda'{*filter*}
> > off the back end of it.

> The best way to learn about unit testing is to ...  do unit testing.
> Your first attempts will feel awkard, but you will improve with time.

> There are several ways to approach unit tests.  You didn't mention a
> particular technique, but I would recommend the "test-first" approach
> where you write your unit test before the production code.  If you
> follow the rule that you never add new functionality to a program
> without a broken unit test, and then only write enough code to make the
> test pass, then you get excellent test coverage with a small investment
> of time (that pays for itself many times over).

> If you are not familiar with the "test-first" approach, there are a
> number of writeups on any of the web sites devoted to XP (Extreme
> Programming).

There's a nice book online available at
http://www.*-*-*.com/

just my 0.02
frank

--
Frank Schmitt
4SC AG          phone: +49 89 700763-0
                e-mail: frank DOT schmitt AT 4sc DOT com



Mon, 21 Nov 2005 15:36:25 GMT  
 
 [ 9 post ] 

 Relevant Pages 

1. Test::Unit::Mock: Mock objects for testing with Test::Unit

2. using test::unit for C++ unit tests

3. Dynamic programming and Unit Testing.

4. UNIT-Testing framework programs for PHP

5. UNIT-Testing framework programs for PHP

6. Test order in Test::Unit

7. Test order in Test::Unit

8. Automating UI tests (was Re: Art of Unit Testing)

9. Unit testing data; What to test

10. Test Tool for Unit Tests?

11. How to test on circular structures,structures and instances of classes

12. COM and unit tests

 

 
Powered by phpBB® Forum Software