Posts
dry up your doubles
Dependency injection is a great way to test a system’s interactions with its external collaborators, like databases and REST APIs. This approach is described in an earlier article (inject you a dependency for great good).
inject you a dependency for great good
It’s usually pretty to easy write tests for pure logic functions, but it’s often the case that the code we’re trying to test wants to make calls to external collaborators – databases, API endpoints, filesystems, clocks, random number generators, or global state. Testing with real collaborators can be slow, brittle, and just generally a pain, and often gives rise to indeterminate behavior or has side effects on other tests.
let it crash
In go, we often find ourselves reflexively checking and handling each and every error that may be returned from each and every function we call. Sometimes it’s better to let some of them slide.
testing for resource cleanup with dependency injection
Testing can be hard. Sometimes we just have to structure things differently.
the coverage is a lie (or is it?)
Unit test coverage is an interesting topic.
subscribe via RSS