Colin Breck

When I complete something that I'm working on, rather than calling it a day, I usually start on the next thing. Not in the hopes of finishing a great deal more work, usually it is just to get a feel for what is in store next. Nothing is

For over a decade, I have worked on infrastructure software for streaming data systems. My experience includes developing and supporting time-series databases, publish-subscribe messaging systems for streaming data, and software for reliable event-data collection. As they are embraced by web companies for making operational and business decisions on-the-order of minutes

I started this blog [https://blog.colinbreck.com/inaugural-post/] a year ago with the intention of sharing some of my work. I think it has gone roughly according to plan. I'm satisfied that I averaged an essay a month — that feels about right for me. Looking back, there

In my last post [https://blog.colinbreck.com/programmatically-generating-tests-using-a-visual-studio-t4-text-template/] , I described why I prefer tests that test only one thing. Naturally, this can lead to a lot of test methods with a fair amount of repetitive code. I presented a technique for programmatically generating tests when doing so by hand

Erik Dietrich's blog series on unit testing [http://www.daedtech.com/tag/starting-to-unit-test] is my favourite introduction to test-driven development (TDD). It is concise, enjoyable to read, and unlike a lot of introductions to TDD that only describe how to write tests, his series focuses on practical considerations

In an earlier post [https://blog.colinbreck.com/disposable-resource-context-classes-for-functional-tests-in-c/], I described how I like to use disposable objects when writing functional tests in C#, to reliably cleanup resources and to promote code reuse across tests. I’ve been writing more tests in C++ recently, so I thought I would revisit

In my previous post [https://blog.colinbreck.com/disposable-resource-context-classes-for-functional-tests-in-c/], I described how I use disposable classes to handle complex initialization and cleanup for functional tests in C#. In this post, I’ll cover some practical considerations for using these contexts. Using Multiple Contexts Some tests require multiple resources. For example,

Automated tests generally follow the Arrange, Act, Assert pattern. First, establish the preconditions of the test, then execute the functionality under test, and, finally, assert that the result meets the expectation. The Arrange portion of a unit test is usually trivial. Functional tests, however, can often have fairly involved preconditions

I was recently part of a team implementing a new cloud service. One of the objectives of this team was to frequently release software to production. This might be a minor patch or the introduction of a significant new feature. After some careful investments in automated builds, deployments and tests,

As I mentioned in my previous post [https://blog.colinbreck.com/tricks-with-windows-performance-counters-for-automated-tests/], I really like using Windows Performance Counters in automated tests to gain insights into applications. It is not difficult to expose custom Performance Counters from your own application to report various metrics. But what about testing these custom

I really like Windows Performance Counters. I find them a powerful tool for understanding applications under development and for monitoring and troubleshooting applications in production environments. Windows Performance Counters are available for reporting absolute values (e.g., Memory\Available Bytes), counts (e.g., Network Adapter\Packets Received Discarded), rates (e.

I've written a lot of automated tests that involve time and time-series data. I've also maintained many similar tests written by others. Given that these tests involve time and sometimes subtle timing, they can often be less deterministic than tests that only involve static data. I&

Unit tests that provide coverage for every exception a method can throw are invaluable. When writing these tests, the developer needs to carefully consider (or reconsider) the exceptions being thrown, along with how they will ultimately be handled by the caller. This exercise alone often results in improvements to the

Welcome to my blog. My intentions are to write about software development, including the temperament and character of individuals, teams, and organizations. I hope to post something new once or twice a month. I don't expect to become a prolific writer, or become the next Joel on Software