order of unit tests

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

order of unit tests

Marc Santhoff
Hi,

currently I'm observing the following behaviour:

- test cases are run in the order of their registration
- testing procedures (per test) are run in the order of their
declaration in the test class

Since I can save a lot of work depending on this orders I'd like to do
so. ;)

Is there any argument speaking against assuming fixed order behaviour?

Not for test suites, as I understand it, but that's fine with me.

TIA,
Marc


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: order of unit tests

Graeme Geldenhuys-2
On Sun, Dec 7, 2008 at 1:08 AM, Marc Santhoff <[hidden email]> wrote:
>
> Since I can save a lot of work depending on this orders I'd like to do
> so. ;)

Could you explain, I don't fully understand your statement.


> Is there any argument speaking against assuming fixed order behaviour?

One of the design guidelines for unit testing is that tests must NEVER
rely on the output of other tests. So the order of tests are really
irrelevant. Any single tests or test suite must be able to run and
pass without first having to run others in a set order.


Regards,
  - Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: order of unit tests

Marc Santhoff
Am Sonntag, den 07.12.2008, 09:20 +0200 schrieb Graeme Geldenhuys:
> On Sun, Dec 7, 2008 at 1:08 AM, Marc Santhoff <[hidden email]> wrote:
> >
> > Since I can save a lot of work depending on this orders I'd like to do
> > so. ;)
>
> Could you explain, I don't fully understand your statement.

I'd like to assume the order is fixed in this case:

Ich have two classes for a special file format. When writing tests I'd
like to

- have one file in the format as a reference data, if
  it can be read the sources are okay
- test the reader component on the reference file
- if the reader is okay, use it to re-read what the
  writer component writes out

That way would avoid duplicating the code actually doing the work of
reading those files from the reader component into the unit test.

> > Is there any argument speaking against assuming fixed order behaviour?
>
> One of the design guidelines for unit testing is that tests must NEVER
> rely on the output of other tests. So the order of tests are really
> irrelevant. Any single tests or test suite must be able to run and
> pass without first having to run others in a set order.

Yes, I agree. But if I do the same reading process in the readers source
and in the test case I have two spots having the same code. Fixing
errors or making changes at one place only would be nice.

How could I solve this problem in a better way?

Regards,
Marc


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: order of unit tests

Tom Verhoeff
On Sun, Dec 07, 2008 at 11:10:19AM +0100, Marc Santhoff wrote:
>
> How could I solve this problem in a better way?

By using SetUp and TearDown routines.

        Tom
--
E-MAIL: T.Verhoeff @ TUE.NL     | Dept. of Math. & Comp. Science
PHONE:  +31 40 247 41 25        | Technische Universiteit Eindhoven
FAX:    +31 40 247 54 04        | PO Box 513, NL-5600 MB Eindhoven
http://www.win.tue.nl/~wstomv/  | The Netherlands
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: order of unit tests

Graeme Geldenhuys-2
In reply to this post by Marc Santhoff
On Sun, Dec 7, 2008 at 12:10 PM, Marc Santhoff <[hidden email]> wrote:
>
> Yes, I agree. But if I do the same reading process in the readers source
> and in the test case I have two spots having the same code. Fixing
> errors or making changes at one place only would be nice.
>
> How could I solve this problem in a better way?

By using Setup() or TearDown().  You can also use class inheritance.
Create TTestCase descendants implementing your readers source. Then
create your actual test cases, using that new class, instead of
TTestCase directly.

eg:
    TTestCase
            |
    TMyBaseReaderTestClass   <------ will contain your reader code
            |
    TReaderTestCase           <-- will contain your actual tests


or


    TReaderTestCase = class(TTestCase)
    public
       procedure Setup;          <--- reader setup code here
       procedure TearDown;
    published
       procedure TestOne;
       procedure TestTwo;
       ....
    end;


Setup() and TearDown() will be called automatically before and after each test.


Regards,
  - Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal