Return to Answer

You're focusing on the wrong thing.

A SymbolPairDto and a couple of prices go in and and a DecisionResponse comes out. So long as you know how to build all of those, and how to compare one DecisionResponse to another this is testable.

The hard part is coming up with the tests. Which is actually less about what goes in and goes out than about what decisions, that is, behaviors, are inside.

Those classes look big and scary but if there’s only a few if’s inside DoAlgorithm making decisions you won’t need that many tests to cover all your cases.

After all, one little int already has way too many values to test each one. That’s why we don’t test that way. We test against the behaviors we need. Not everything that could possibly happen.

Given that, I care more about what DoAlgorithm is supposed to do than about how ugly this other stuff is. Long as I can build them and compare them I’m good.

You're focusing on the wrong thing.

A SymbolPairDto and a couple of prices go in and and a DecisionResponse comes out. So long as you know how to build all of those, and how to compare one DecisionResponse to another this is testable.

The hard part is coming up with the tests. Which is actually less about what goes in and goes out than about what decisions, that is, behaviors, are inside.

Those classes look big and scary but if there’s only a few if’s inside DoAlgorithm making decisions then you won’t need that many tests to cover all your cases.

After all, one little int already has way too many values to test each one. That’s why we don’t test that way. We test against the behaviors we need. Not everything that could possibly happen.

Given that, I care more about what DoAlgorithm is supposed to do than about how ugly this other stuff is. Long as I can build them and compare them I’m good.

You're focusing on the wrong thing.

A SymbolPairDto and a couple of prices go in and and a DecisionResponse comes out. So long as you know how to build all of those, and how to compare one DecisionResponse to another this is testable.

The hard part is coming up with the tests. Which is actually less about what goes in and goes out than about what decisions, that is, behaviors, are inside.

Those classes look big and scary but if there’s only a few if’s inside DoAlgorithm making decisions you won’t need that many tests to cover all your cases.

After all, one little int already has way too many values to test each one. That’s why we don’t test that way. We test against the behaviors we need. Not everything that could possibly happen.

Given that I care more about what DoAlgorithm is supposed to do than about how ugly this other stuff is. Long as I can build them and compare them I’m good.

You're focusing on the wrong thing.

A SymbolPairDto and a couple of prices go in and and a DecisionResponse comes out. So long as you know how to build all of those, and how to compare one DecisionResponse to another this is testable.

The hard part is coming up with the tests. Which is actually less about what goes in and goes out than about what decisions, that is, behaviors, are inside.

Those classes look big and scary but if there’s only a few if’s inside DoAlgorithm making decisions you won’t need that many tests to cover all your cases.

After all, one little int already has way too many values to test each one. That’s why we don’t test that way. We test against the behaviors we need. Not everything that could possibly happen.

Given that, I care more about what DoAlgorithm is supposed to do than about how ugly this other stuff is. Long as I can build them and compare them I’m good.

A SymbolPairDto and a couple of prices go in and and a DecisionResponse comes out. So long as you know how to build all of those, and how to compare one DecisionResponse to another this is testable.

The hard part is coming up with the tests. Which is actually less about what goes in and goes out than about what decisions, that is, behaviors, are inside.

Those classes look big and scary but if there’s only a few if’s inside making decisions you won’t need that many tests to cover all your cases.

After all, one little int already has way too many values to test each one. That’s why we don’t test that way. We test against the behaviors we need. Not everything that could possibly happen.

Given that I care more about what DoAlgorithm is supposed to do than about how ugly this other stuff is. Long as I can build them and compare them I’m good.

You're focusing on the wrong thing.

A SymbolPairDto and a couple of prices go in and and a DecisionResponse comes out. So long as you know how to build all of those, and how to compare one DecisionResponse to another this is testable.

The hard part is coming up with the tests. Which is actually less about what goes in and goes out than about what decisions, that is, behaviors, are inside.

Those classes look big and scary but if there’s only a few if’s inside DoAlgorithm making decisions you won’t need that many tests to cover all your cases.

After all, one little int already has way too many values to test each one. That’s why we don’t test that way. We test against the behaviors we need. Not everything that could possibly happen.

Given that I care more about what DoAlgorithm is supposed to do than about how ugly this other stuff is. Long as I can build them and compare them I’m good.