Core
Testability and Dependency Injection
Code that reaches out to the clock, the network, the filesystem, or a random generator cannot be tested deterministically, because its output depends on the world. The fix is to separate pure logic from side effects and inject the things that touch the world (the clock, I/O, randomness) so a test can pass fakes. When you inherit untestable code, pin its current behavior with a characterization test first, then refactor under that net.
a free account unlocks the core curriculum tier · no card
Related course lessons
- Translate source data without losing its meaning →
30 min · Free
Foundations of Forward Deployed Engineering · syllabus - Choose the integration path that meets the workflow and can be operated →
24 min · Free
The FDE Engagement · syllabus - Leave tests that catch regressions and explain their limits →
30 min · Free with sign-in
Foundations of Forward Deployed Engineering · syllabus
Related concepts
Practise this in questions
Coding & DSABuild a time-based KV store, write three real unit tests for it, then defend a locking strategy →hard · PremiumCoding & DSARefactor a tangled 200-line function so it's testable. Walk through your approach. →medium · PremiumCoding & DSADesign a class that returns the moving average of the last N values in a stream →easy · FreeCoding & DSABuild a wc-lite: count lines, words, and characters in text, with flags, factored for extension →easy · FreeMLOps & ML EngineeringHow did you ensure quality and testing on top of your MLOps pipeline? →medium · FreeCoding & DSADesign and implement an LRU cache with O(1) get and put →medium · Free
