# Testing QuickFIX

The development of QuickFIX has been driven by a suite of functional acceptance tests and unit tests. We have been working incrementally, functional test by functional test, writing the unit tests before the code. If these tests pass, we're pretty confident that the engine works as intended.

The developer unit tests are written in C++ and make direct calls into the code. The functional acceptance tests are scripted FIX messages that are pumped into a running FIX server. Most of these tests are based off of the FIX Session-level Test Cases and Expected Behaviors document

Two executable files are built that allow you to run tests. They are ut(.exe) and at_server(.exe). Running the ut executable will run all the defined unit tests against the quickfix library. The at_server executable is an implementation of a FIX server application that simply echoes NewOrderSingle messages back to the client. It also ensures a ClOrdID is not reused. It has just enough functionality to test the application-level behavior of our implementation.

The output of the unit test runner is represented by a period if the test passes or a letter 'F' if it fails. Failed tests will also display information regarding the failure. This will usually be a test name, file name, and line number.

The output of the acceptance test runner will be an XML output that has a result field with a sucess or failure. A failed test will also display information on why the test has failed. Usually this will be a comparison of the expected result and the actual result of a line. To run acceptance tests, ruby must be installed and in your path.

- Windows
- Linux / Solaris / FreeBSD / Mac OS X

### Windows

#### Unit Tests Enter the test directory under quickfix. All tests need to be run from this directory. To run unit tests, either type runut debug [port] or runut release [port], depending on if you want to test the debug or release version. The port is used to test socket functionality. If you built QuickFIX with one of its supporting databases, you will need to update cfg/ut.cfg to reflect your database settings. #### Acceptance Tests Go to the test directory under the root quickfix directory. Type either runat debug [port] or runat release [port], depending on if you want to test the debug or release version. The port is used to listen for connections on a socket server. This should be a port that is not already in use on your system. runat_threaded.bat is also provided if you want to test using threaded socket code. The parameters are the same.

### Linux / Solaris / FreeBSD / Mac OS X

#### Unit Tests Enter the test directory under quickfix. All tests need to be run from this directory. To run unit tests, type ./runut.sh [port] where the port is used to test the socket functionality. If you built QuickFIX with one of its supporting databases, you will need to update cfg/ut.cfg to reflect your database settings. #### Acceptance Tests Go to the test directory under the root quickfix directory. Type ./runat.sh [port]. The port is used to listen for connections on a socket server. This should be a port that is not already in use on your system. runat_threaded.sh is also provided if you want to test using threaded socket code. The parameters are the same.