Colin Breck

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've written tests that passed

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 [http://www.