November 2014

Volume 29 Number 11

Editor's Note : Putting Async to the Test

Michael Desmond | November 2014

The lead articles in this issue of MSDN Magazine focus on a shared theme: Managing the task of unit testing asynchronous code projects.

Stephen Cleary has written extensively about async development over the past couple years here at MSDN Magazine, and his feature article, “Unit Testing Asynchronous Code,” explores how unit testing must be adapted to prove out async projects. He looks at some of the current unit testing frameworks—such as MSTest, NUnit and xUnit—and offers strategies for ensuring best results. Sven Grand follows up with the second feature article in this issue, “Unit Testing Asynchronous Code: Three Solutions for Better Tests.” He offers up three solutions for improving the design of tested async code with the goal of eliminating unit tests that are slow and fragile.

Of course, async programming is a topic of ongoing concern here at MSDN Magazine. Back in the October 2011 issue, Microsoft experts Eric Lippert, Mads Torgersen and Stephen Toub wrote a trifecta of async-themed features that previewed the new async and await keywords in Visual Studio 2012 (msdn.microsoft.com/magazine/hh463583). Since then, we’ve published nearly a dozen feature articles focused on async development. One of those—Cleary’s March 2013 article, “Best Practices in Asynchronous Programming”—is among the most-read articles in the past two years (msdn.microsoft.com/magazine/jj991977).

The point is, async is a hot topic—and for good reason. As Grand writes in his article this month, “Whether for CPU-based parallelism or IO-based concurrency, developers are employing asynchrony to help make the most of the resources available and ultimately do more with less. More responsive client applications and more scalable server applications are all within reach.”

The benefits of async development are clear—particularly in an increasingly cloud-driven world—but async programming poses a challenge for developers who are new to the practice. As Cleary says in an interview: “A lot of async tutorials explain how to use async/await, but they don’t prepare developers for the viral nature of async. So when they start out writing a single async method and this async/await stuff keeps growing through their code, the warnings go off and they search for verification that this is actually correct.”

Which is why this month’s issue of MSDN Magazine leads off with a pair of articles focused on unit testing asynchronous code. Testing is one of those things that can get pushed to the side when timelines get tight. Yet, a rigorous and disciplined test regime is critical to achieving consistent code quality. The two features this month help developers ensure their async development happens in a well-structured and supported environment.

“Most of the challenges for unit testing asynchronous code are the same as unit testing synchronous code. Code is easier to test when it’s designed well,” Cleary says. “For asynchronous code, a more functional approach can be helpful—in other words, return results rather than setting values as side effects.”

Grand says it’s important to focus testing efforts, as developers can end up testing library code that’s being called from custom code. “You don’t need to write a test to ensure Microsoft Task.Run really works. Believe me, it works. Your tests get simpler and cleaner if you manage to test only your own code,” Grand says.

Is your dev shop writing asynchronous code and how have you adapted your testing to accommodate it? E-mail me at mmeditor@microsoft.com.

Michael Desmond is the Editor-in-Chief of MSDN Magazine.