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