In software development there is a technique called
Test Driven Development which is a process of taking requirements of a project and breaking these requirements down into cases which will be accepted if proven. These test are often derived from user stories and are typically broken down into unit test which test expectation of a function or method, as well as integration test which test a feature from end to end.
There are two common ways of testing. One is to write the test the code is expected to pass first, and the other is to write the code then test against it. What I'm interested in exploring from these concepts is how traders can incorporate this thinking to test their plan, debug inefficiencies, as well as introduce new concepts without breaking the current flow of execution. How can traders approach their trading from the perspective of a software developer?
The process of an integration test can be used to develop a process from how to approach studying to setting alerts, entry, stop placement, and exit. Once we have applied the theory of integration test we can apply the concepts of unit test for handling the minutia of a trading plan whether it be entry, placing a stop, or exiting a position. For this I'm going to look at one specific syntactic approach: Given, When, Then.
Given, When, Then is a syntax that when coupled with Feature and Scenario complete an approach called Behavior Driven Development. In this approach a small chunk of the trading plan such as an exit can be broken down such as:
Feature: I have an open position
Scenario: Exiting the position
Given: A trade hits my target
When: I take half off
Then: I will move my stop to break even on remainder.
Feature: Half Sized Open Position
Scenario: Exiting the position
Given: A trade hit my target and I moved my stop to break even
When: Price hits 20% from entry
Then: I will exit the remainder position
Now, when reviewing previous trades or searching through previous winners we have a focused set of criteria to pay attention to. We can better understand how our previous trades would have worked under these guidelines. Additionally since these test are being applied to the minimal amount of execution on our part, complexity setting in can be more easily identified by noticing when the test are getting too verbose and have too many steps or moving parts. And, while these test may pass on past data, a complete integration test of this on one's actual trading plan may not work out as expected.
Simply because something worked in hindsight doesn't mean I will be able to execute. As such, whenever I make a modification to a critical part of my trading plan such as an exit, I drop down in size and take twenty trades. I don't assume I am going to act in accordance and can not presume potential frustration should this new exit technique not work under current market conditions or be psychologically comfortable to me. By dropping down in size I reduce the risk to capital and some of the stressors associated with a position size I may not be comfortable. Being undersized when using these parameters increases my chance of success in abiding by the rules and achieving a large enough sample size to be meaningfully analyzed.
Additionally, thinking in terms of test prevents straying from one's trading plan when making adjustments. Often when something isn't working traders will jump ship and adopt a different trading style instead of maintaining a consistent philosophy and making necessary adjustments. Through testing each function of the trading plan it become easier to isolate and identify where potential problems are creeping in and handle them accordingly.
