I didn’t learn until I picked up the book that Test-Driven Development (TDD) originated from Test-First Programming in Kent Beck’s Extreme Programming Explained. I’ve been doing TDD for years, but I recently listened to an episode of the Embedded.fm podcast where James Grenning described how to get started with TDD and it was profound.

“Write a test.”

— James Grenning

He goes on to add plenty of wisdom to the above, but I agree with this simple advice. I always recommend a good way to get started testing is to do a simple return type assertion. I’ll demonstrate in my most familiar language C#:

[TestMethod]
public void ReturnsInt()
{
  var result = _query.Execute();
  
  Assert.IsInstanceOfType(result, typeof(int));
}

The simplicity of this test really helped me get going when I was first learning TDD and would find myself stuck, unsure of how to proceed or what to test. Imagine you were asserting that a change machine at the laundromat returns quarters, instead of dimes or nickels. It’s worth making sure that your type is correct, and from here you can create your class and method under test until your test compiles and passes.

The value of knowing how to get started testing cannot be understated. Once you build a little momentum, each successive test is a little easier to write. Testing output of a function given certain inputs is a type of black box testing where you don’t care about the implementing code, just the results. I consider these a kind of first order test due to their ability to cover the inner logic deterministically.

Do you find yourself wondering what test I write first for a void function? That’s a more challenging case, since a void function is almost certainly changing the application state, and I consider these second order tests. I’ll certainly show you more strategies in a future blog post, so keep reading!