212 CHAPTER ◆ 2 2 Build and Document the System
detect defects within the system as a whole. (System testing makes sure the software and
hardware are working right, not whether the trading system makes money.)
During system testing, the development team should throw everything possible at the
system, up to and beyond the bounds defined in the requirements specification. In the
end, system testing is important, but its limits must be recognized. Design flaws can often
be picked up early on by running the program in an emulated environment. Most testing
is done by simulation of the environment, but it is difficult to provide realistic test exer-
cises (can we simulate all possible price changes in markets? Including extreme cases and
gaps?). Furthermore, it is difficult to predict and simulate all failure modes of the system;
and hardware failures can complicate things. System testing is the final test undertaken
by the development team before the product team engages in user acceptance testing.22.7. Summary
Any trading/investment system will consist of proprietary and off-the-shelf components.
New software should be unit tested; components that work together should be integra-
tion tested; and the completed software and hardware implementation should be system
tested. Code reviews are critical for finding and fixing bugs.
Every software module has three functions: its intended functionality, its ability to
change, and its communication to the consumer of its services. Test-driven development
should ensure both interfaces and functionalities are emphasized. Since all trading sys-
tems and all code will likely change over the lifetime, sound coding and documenta-
tion practices are critical. It is the responsibility of programmers to make sure that such
changes are as simple as possible to make. Developers unfamiliar with the module should
be able to read and understand code documentation without undue mental gymnastics.22.7.1. Best Practices
● Plan and conduct unit, integration, and system tests.
● Use instrument-centric OOP and stored procedures where possible.
● Refactor, refactor, refactor.
● Document code thoroughly while coding, not at the end.
● Stick to the fundamentals.