Difference between revisions of "fpcunit"

From Free Pascal wiki
Jump to navigationJump to search
(→‎Tests: assertion behaviour)
Line 63: Line 63:
 
end;
 
end;
 
</syntaxhighlight>
 
</syntaxhighlight>
 +
 +
==Output==
 +
The console test runner can output in XML, plain text and latex formats. The GUI test runner outputs to XML if needed.
 +
 +
You can use your own "listener" that listens to the test results and outputs the test data in whatever way you want.
 +
Simply create a TDatabaseListener that implements the ITestListener interface. It's only 5 required methods to implement.
 +
 +
***to do: find out and describe***
 +
In your test runner application, add a listener object; register that test listener with the testing framework (e.g. your console test runner) via the TestResult.AddListener() call, and it will be fed test results as they happen. An example of an available listener is TXMLResultsWriter in the xmlreporter unit in  <fpc>\packages\fcl-fpcunit\src\xmlreporter.pas.
  
 
==Alternatives==
 
==Alternatives==

Revision as of 16:28, 29 September 2012

Overview

fpcunit is a unit testing framework a la DUnit/JUnit/SUnit. This allows you to quickly write a set of test for a (logical) unit of code (not necessarily the same as a Pascal unit, though often it is).

Development methodologies like Test Driven Design use this to make sure you code your expectations/specifications in your unit tests first, then write your main code, then run your tests and improve the code until all tests pass.

Not only does fpcunit allow you to visually inspect test runs, you can also collect the results systematically (using the XML output), and use that to compare versions for e.g. regression errors (i.e. you run your regresssion tests using the unit test output).

Screenshot of the GUI test runner: guitestrunner.png The image shows that out of 10 tests run, 6 tests failed. The EAssertionFailure exceptions indicate the test assertions (see below) were not met - i.e. the test failed. The associated messges indicate the result the test expected and the actual result achieved.

Use in FPC/Lazarus

FPCUnit tests are used in the FPC database test framework: Databases#Running_FPC_database_tests

There are also tests for the FPC compiler/core packages, but these presumably predate fpcunit and use a simpler approach.

Use

It's easiest to use Lazarus to set up a new test project for you.

Setup

This procedure is present in all FPCUnit tests. It sets up the test environment before each test is run. You can use this to e.g. fill a database with test data.

Teardown

This procedure is present in all FPCUnit tests. It cleans up the test environment after each test is run. You can use this to e.g. clear test data from a database.

Tests

You write your own tests as published procedures in the test class. You can use AssertEquals etc to specify what should be tested.

If the test fails, an EAssertionFailedError will be raised with the message you specify in Assert*. This way, you can add a series of subtests and tell which subtest failed. Note: the test runner will stop at the first assertion failure, so subsequent subtests will not be performed. If you do want to always test everything, split out these subtests in separate test procedures.

The order in which the tests are run are the order in which they appear in the test class definition.

Example test:

  Ttestexport1 = class(Ttestcase)
...
  published
    procedure TestOutput;
...
procedure Ttestexport1.TestOutput;
const
  OutputFilename='output.csv';
begin
  TestDataSet.Close;

  if FileExists(OutputFilename) then DeleteFile(OutputFileName);
  TestDataset.FileName:=OutputFileName;
  TestDataset.Open;
  // Fill test data
  TestDataset.Append;
  TestDataset.FieldByName('ID').AsInteger := 1;
  // Data with quotes
  TestDataset.FieldByName('NAME').AsString := 'J"T"';
  TestDataset.FieldByName('BIRTHDAY').AsDateTime := ScanDateTime('yyyymmdd', '19761231', 1);
  TestDataset.Post;

  TestDataset.Last;
  TestDataset.First;
  TestDataset.First;
  AssertEquals('Number of records in test dataset', 1, TestDataset.RecordCount);
  TestDataset.Close;
end;

Output

The console test runner can output in XML, plain text and latex formats. The GUI test runner outputs to XML if needed.

You can use your own "listener" that listens to the test results and outputs the test data in whatever way you want. Simply create a TDatabaseListener that implements the ITestListener interface. It's only 5 required methods to implement.

      • to do: find out and describe***

In your test runner application, add a listener object; register that test listener with the testing framework (e.g. your console test runner) via the TestResult.AddListener() call, and it will be fed test results as they happen. An example of an available listener is TXMLResultsWriter in the xmlreporter unit in <fpc>\packages\fcl-fpcunit\src\xmlreporter.pas.

Alternatives

There is DUnit2 (IIRC an improvement of the original DUnit), originally written for Delphi, which is in use in the tiOPF framework.

Also available is FPTest.

Lazarus

Lazarus has the consoletestrunner and GUI test runner units, which can be installed by installing the FPCUnitTestRunner package. This will help you create and run your unit tests using a GUI (or console, if you want to).

The consoletestrunner is compatible with FPC so you don't need Lazarus to compile it. The Lazarus version is slightly different to the one in FPC (e.g. use of UTF8 output etc).

The GUI runner is easier to use.

In the GUI runner, if you want to run all tests, currently you first need to click on a test element before the Run all tests button is activated.

GDB bug/feature

Note (September 2012): a bug/undocumented feature in the debugger used by Lazarus/FPC (gdb) means that passing --all as run parameters has no effect. Passing this parameter can be useful when debugging console fpcunit test runners has no effect. Workaround: use -a. See bug [1]