With Dist::Zilla (dzil), testing Perl projects on Travis CI can be a bit tricky. Here's my approach.

When does it make sense to keep integration tests separate from your unit tests, and when is it OK to make no distinction?

Well, it's all about getting fast feedback.

This post contains a bunch of ideas on testing custom allocators in C, assuming a single-threaded scenario.

Global dependencies make it difficult to properly test a piece of code. By extracting all dependencies into a single manageable object, we can easily mock the necessary services and avoid a large-scale refactor.

I'm currently refactoring a huge method into smaller parts. It is stock full of nested loops, maintains a complex state machine with more variables than I have fingers, and is the kind of code where I have to ask myself how I could ever think this would have been a good idea. So obviously, I'm splitting that function into smaller, independent chunks with the Extract Method refactoring technique.[^1] Since the control flow is now simplified, the code has also become easier to test – as long as I'm comfortable with testing private methods. Why?

The number of test cases needed for full path coverage corresponds directly to the McCabe complexity of the code under test. Since many simple functions often have lower total complexity than one convoluted function, the overall required testing effort is reduced. As this reduction can be substantial, there is a strong incentive to test the extracted methods directly, instead of testing only through the public interface.