TDD cheats, tricks to dodge the hard parts of testing
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”
Comment on the blog!
Create a comment by emailing me.Open an email to start writing.
I will then add the comment to the post.