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

Marc Santhoff 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/

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.

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

Marc Santhoff wrote

How could I solve this problem in a better way?

By using SetUp and TearDown routines.

Tom

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/