Two frog figurines. One is pulling a cabin bag. The other has one bag in each hand.

Test Driven Development is sometimes hard. I have found some “cheats” to make it easier.

Test gets too big and complicated

Split up the thing you are testing. Create a collaborator and test that separately or just split up the function. Splitting up view logic and rendering is nice and make testing easier.

Cheat codes: “separation of concerns”, “model view controller”, “view model - model view”

State makes things hard

Sometimes the test depends on a system state or some other thing that is hard to control in the test. Inject the tricky thing as a dependency (fancy word for parameter) to the function/method. Today’s date should always be injected as a dependency if used.

Cheat codes: “dependency injection”

The framework I am using has no test doubles

Wrap the framework in your own code and create a double for the wrapper. That will also isolate the framework, make it easier to adapt, replace and upgrade.

Cheat code: “ports and adapters”, “Hexagonal design”

I do not understand mocks, stubs, fakes and all the tricky words

Try to avoid side effects in your code as far as possible. Isolate necessary side effects (as sending/getting data) to specific areas of the code — the shell. A function or method that does not return anything, aka a void function, is a sign of a side effect in action. Make sure void functions do not contain any conditionals (if etc.). Write the rest of the code without side effects, levering data. If that is the only place containing logic, it is the part most important to test. And that can be done without tricky things as mocks.

Cheat code: “pure functions”, “io monads”, “functional core - imperative shell”

Sources:

https://www.destroyallsoftware.com/talks/boundaries

Related texts

A single frosted leaf with clear contours and veins.

TDD in the context of writing code to be read

Wunder Baum hanging from a car window (Known as Little Trees in most English-speaking countries)

Wunderbaum testing