Building QuickFIX/J

Runtime Dependencies

JMV compatible with Java 1.4.x or higher.

Required run-time libraries:

Optional run-time libraries:

Building QuickFIX/J

These instructions are for developers who don't want to use the prebuilt binaries or are intending to modify and rebuild the QuickFIX/J code. If you are building the code from the command line you'll need to download and install Ant (version 1.6.3 or newer). If you are building from Eclipse, Ant is included.

1. Check out the code from CVS using anonymous access. See the anonymous CVS directions at Source Forge for more details on access. You will want to checkout the quickfixj module (notice the 'j' at the end).
2. Change directory to the top-level directory of the checked out code. You should see a build.xml file.
3. Run ant jar to build the QuickFIX/J and examples jar files. This will also generate all the FIX message-related code for the various FIX versions.

Eclipse IDE support:

The QuickFIX/J developers also use Eclipse to build the software. There is a project definition in the top-level directory of the checked out CVS workspace. In fact, if you are an experienced Eclipse developer you may want to check out the project directly from Eclipse. There is an external builder for running the Ant target to generate the message-related Java classes. If you are seeing compile errors related to message classes, the builder may not have run for some reason. If so, you can generate the classes by running the generate.code target in the Ant build.xml file.

Generating the MySQL Database

Everything needed to generate your MySQL database is in the src/sql directory. Here, there are the script and batch files create_mysql.sh and create_mysql.bat. These scripts will work on a newly installed mysql database with default permisions. The scripts will try to generate the database using the root MySQL account with no password. If you need to use a different account or need a password, you will have to edit the script. To select a different user, simply change 'root' to another user. To add a password, use pass the -p option after the username.

Testing QuickFIX/J

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 reasonably confident that the engine works as intended.

The developer unit tests are written as JUnit tests and test the code directly. 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.

The unit tests can be run by running the test.unit target in the Ant build.xml file. If you are using Eclipse, you can right-click on the quickfix package in the test subdirectory and select the "Run as... -> JUnit Test" option. This should locate all the unit tests in the package hierarchy and run them in the integrated JUnit test runner.

Acceptance Tests

QuickFIX/J also has a scriptable test runner that comes with a series of automated acceptance test. The basic tests that come with QuickFIX are based off of the FIX Session-level Test Cases and Expected Behaviors document produced by the FIX protocol organization. These tests verify that QuickFIX adheres to the FIX specifications. The automated nature of these tests guarantees that future releases of QuickFIX will not break any current functionality.

Perhaps even more importantly is how these test are used to drive the development of QuickFIX. Before a line of code is written in support of a protocol feature, one of these tests is written. This test first approach sets up a goal for developers who will have objective verification that they correctly implemented the standard.

To run the acceptance tests, use the test.acceptance Ant target. If you are using Eclipse, right-click on the quickfix.test.acceptance.AcceptanceTestSuite class and select the "Run as... -> JUnit Test" option. This will start an acceptance test program with an embedded QuickFIX/J server, load the AT definition files and convert them to JUnit tests, and run those tests in the embedded JUnit test view.

Writing your own Acceptance Test Scripts

Below is an example of a test script that tests the engines behavior when it receives a NewSeqNo value that is less than the expected MsgSeqNum.

  iCONNECT
  I8=FIX.4.2
35=A
34=1
49=TW
52=<time>
56=ISLD
98=0
108=30

  E8=FIX.4.2
9=57
35=A
34=1
49=ISLD
52=00000000-00:00:00
56=TW
98=0
108=30
10=0


  # sequence reset without gap fill flag (default to N)
  I8=FIX.4.2
35=4
34=0
49=TW
52=<time>
56=ISLD
36=1

  E8=FIX.4.2
9=112
35=3
34=2
49=ISLD
52=00000000-00:00:00
56=TW
45=0
58=Value is incorrect (out of range) for this tag
372=4
373=5
10=0


  I8=FIX.4.2
35=1
34=2
49=TW
52=<time>
56=ISLD
112=HELLO

  E8=FIX.4.2
9=55
35=0
34=3
49=ISLD
52=00000000-00:00:00
56=TW
112=HELLO
10=0


  # sequence reset without gap fill flag (default to N)
  I8=FIX.4.2
35=4
34=0
49=TW
52=<time>
56=ISLD
36=1
123=N

  E8=FIX.4.2
9=112
35=3
34=4
49=ISLD
52=00000000-00:00:00
56=TW
45=0
58=Value is incorrect (out of range) for this tag
372=4
373=5
10=0


  I8=FIX.4.2
35=1
34=3
49=TW
52=<time>
56=ISLD
112=HELLO

  E8=FIX.4.2
9=55
35=0
34=5
49=ISLD
52=00000000-00:00:00
56=TW
112=HELLO
10=0

  iDISCONNECT
  

Action Commands

Message Commands

When using the I command, you do not need to add the Length(9) or the CheckSum(10) fields, they will be added for you with the correct values in the appropriate locations. The only time you would add these fields is if you intentionally wish to make them incorrect.

The I command also provides a TIME macros for fields. By setting a field equal to <TIME>, the current system time will be placed in the field. (i.e. 52=<time>). You can also use offsets such as 52=<TIME-120> or 52=<TIME+15> in order to set the time plus or minus some seconds from the current time.

The E command verifies that you have received the correct message. This command will compare the values of each field to make sure they are correct. Some fields cannot be verified deterministically before run-time such as the SendingTime and CheckSum fields. These fields can be added to the fields.fmt file where a regular expression can be defined to at least verify the field is in the correct format. For example: