Acceptance Tests

QuickFIX 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.

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.


# sequence reset without gap fill flag (default to N)
E8=FIX.4.29=11235=334=249=ISLD52=00000000-00:00:0056=TW45=058=Value is incorrect (out of range) for this tag372=4373=510=0


# sequence reset without gap fill flag (default to N)
E8=FIX.4.29=11235=334=449=ISLD52=00000000-00:00:0056=TW45=058=Value is incorrect (out of range) for this tag372=4373=510=0

In these script there are two types of commands, action commands and messages commands. Action commands begin with lowercase letters while message command begin with uppercase letters.

Action Commands

i<ACTION> - initiates an action
e<ACTION> - expect (wait for) an action

Supported actions are:

iCONNECT - initiate connection to a FIX acceptor
eCONNECT - expect a connection from a FIX initiator
iDISCONNECT - initiate a disconnect
eDISCONNECT - expect a disconnect

Message Commands

I<MESSAGE> - initiate (send) a message
E<MESSAGE> - expect (wait for) a message

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 macro 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:

10=\d{3}, checksum must be exactly three digits
52=\d{8}-\d{2}:\d{2}:\d{2}, sending time must be in the form of DDDDDDDD-DD:DD:DD where D is a digit.

Either command can contain a FILE macro which puts the contents of a file into a field (i.e. 58=<FILE:test.txt>)