Tests

A program is only as good as its tests. Accordingly, FixConv comes with a simple command-line test program that can be used for one-off conversions, and also to test it.

The test program

To run the test program :-

java -cp target/fixconv-<VERSION>.jar org.fixprotocol.contrib.converter.FixConvTest
usage: FixConvTest xmlToTag FixRepository.xml file.fixml [file.tag [extMaj [extMin [extSP [extEP [extCv]]]]]]
   or: FixConvTest tagToXml FixRepository.xml file.tag [file.fixml [extMaj [extMin [extSP [extEP [extCv]]]]]]
   or: FixConvTest repair FixRepository.xml file.tag [file2.tag [extMaj [extMin [extSP [extEP [extCv]]]]]]
   or: FixConvTest pretty FixRepository.xml file.tag [extMaj [extMin [extSP [extEP [extCv]]]]]
   or: FixConvTest validate file.fixml fixml-main-X-X.xsd

This can be used to convert either way, eg: to convert from FIXML to tag=value :-

java -cp target/fixconv-<VERSION>.jar org.fixprotocol.contrib.converter.FixConvTest \
xmlToTag src/test/resources/FixRepository-2010_Subset.xml file.fixml

To do the same, and keep the result in a file :-

java -cp target/fixconv-<VERSION>.jar org.fixprotocol.contrib.converter.FixConvTest \
xmlToTag src/test/resources/FixRepository-2010_Subset.xml file.fixml file.fixml.tag

If the input FIXML file has a Batch of messages, and it contains more than one message, then several output files are written, with filenames ending in -1, -2, etc..

To convert back :-

java -cp target/fixconv-<VERSION>.jar org.fixprotocol.contrib.converter.FixConvTest \
tagToXml src/test/resources/FixRepository-2010_Subset.xml file.tag

and keep the result (without overwriting the original) :-

java -cp target/fixconv-<VERSION>.jar org.fixprotocol.contrib.converter.FixConvTest \
tagToXml src/test/resources/FixRepository-2010_Subset.xml file.tag file.tag.fixml

The test program displays the message before translation, some debug tracing (which isn't normally shown when using the FixConv classes), and the output message(s). tag=value messages are shown in a debug printable form, ie: using the .toString() method described earlier, thus resulting in \xHH notation in the output.

The repair command reads a tag=value message and if the BodyLength (9) field is missing, it inserts and calculates it. If the CheckSum (10) field is missing, it appends and calculates it. This is handy because sometimes people write sample test messages using text editors and omit these fields (or get them wrong). Some text editors also append newline characters (\n or \r\n) to the end of the line - this test program silently truncates these unwanted additions.

The pretty command dumps the fields in a tag=value message, one to a line, annotating each with the tag name.

If you have the schemas handy, the validate command can be used to check your FIXML file for validity. Validation errors are displayed, and silence is good. If a FIXML message is valid, this program should be able to convert it to tag=value. When tag=value messages are converted to FIXML, they should be valid.

Note that the FIX Converter can convert session tag=value messages to FIXML, but note that these will fail to validate against the FIXML XSDs. This is not because there is anything wrong with them structurally, its just that the folks behind the Unified FIX Repository have decided that FIX session messages are not requred in FIXML. Looking at the 2010 Edition of the repository, I can see a problem in the way the FIX.4.4 Logon message is defined (it has a NoMsgTypes repeatingGroup directly within the message, rather than nested within a component which is componentRefd from the message. This prevents the correct generation of FIXML for that message.

The test data

src/test/resources/FixRepository-2010_Subset.xml is a stripped down subset of the 2010 Edition of the Unified FIX Repository, included for testing purposes.

src/test/resources/messages/ contains many sample tag=value messages (with .tag file extension), and many sample FIXML messages (with .fixml file extension).

The message filenames typically reflect the nature of their content, and the problem with the data, and sometimes the expected result. Sometimes the content itself includes comments regarding the expected result. eg: fix44-malformed-tag.tag.

The result of doing a xmlToTag on a .fixml file is captured in a corresponding .fixml.tag file, and a log of the conversion process (captured from stdout) in a .fixml.log file. If a FIXML file converts to more than one tag=value file, then the filenames end in -<NUMBER>.fixml.tag.

The result of doing a tagToXml on a .tag file is captured in a corresponding .tag.fixml file, and a log of the conversion process (captured from stdout) in a .tag.log file.

Test messages have been difficult to source, and in many cases have been created by getting sample or real messages and cleaning them up so that they validate. Some came from the FPL site and some are real messages with names changed to protect the guilty. Some are designed to exercise specific functionality and some are designed to be defective in specific ways.

The test data covers :-

  • Bad tags (malformed, and not valid in this version of FIX)
  • Bad message type (not valid in this version of FIX)
  • Bad XML message structure (element ordering)
  • Version and custom version of FIX not in the repository
  • Inconsistent version information
  • Correct XML element structure and incorrect
  • Fields in order, or not, to varying degrees
  • Repeating groups, good and badly formed (eg: zero repetitions)
  • Encoded text fields
  • data fields
  • Session tag=value to FIXML (which then doesn't validate, as expected)

Note that with the encoded data samples, although the data is right in the input and output files, it won't look right on the standard output because the terminal typically doesn't use the right encoding.

The test data described above is what the JUnit tests use.