How To Capture Test Output in xUnit 2.0

As of xUnit 2.0 the test framework no longer captures any native outputs, this is by design. Now the question is: where do you write your test output?

You now have to write all test output to an interface, ITestOutputHelper, that is injected into your test's constructor. This design seems to have polarized developers a bit, as not everyone enjoys being require to add a constructor to your test classes. Personally, as a huge fan of dependency injection, I really like this solution.

Spoilers: My next blog post will be about how to combine this with Common.Logging and NLog.

Sample Test

using System.Threading.Tasks;

using Xunit;

using Xunit.Abstractions;

namespace XUnitDemo

{

    public class OutputTests

    {

        private readonly ITestOutputHelper _testOutput;

        public OutputTests(ITestOutputHelper testOutput)

        {

            _testOutput = testOutput;

        }

        [Fact]

        public async Task WriteLine()

        {

            _testOutput.WriteLine("Hello");

            _testOutput.WriteLine("World");

            await Task.Delay(1000);

            _testOutput.WriteLine("Goodnight");

            _testOutput.WriteLine("Moon");

        }

    }

}

Enjoy,
Tom

Three Things that all Applications MUST Have

This is the first in a three part series:

1. Three Things that all Applications MUST Have
2. Three Things that all Applications SHOULD Have
3. Three Things that all Applications SHOULD WANT to Have

I feel very strongly that when you start a new project you should spend your first day or two just setting up a few basic utilities. For every hour you spend at the beginning of a project setting up these tools you will save yourself days down the line.

1. Logging

What is your application doing? How can you debug it? Will that work in all environments? The go to answer for these questions should always be logging!

I am constantly amazed at how many applications do not have a logger. To be fair, most of the time when I do not see a logger it is because the application is small or started out as a one off project. However to me that is all the more reason to just take the time and setup a logger right from a project's inception, then you know it will always be there. Thick client, thin client, or back end service, it should have a logger!

• log4net
• NLog
• Common.Logging

2. Dependency Injection

Dependency Injection is a pattern that drives a lot of best practices: it allows you to loosely couple your modules, forces you to consider the number dependencies any given module requires, and perhaps most importantly it makes your code very testable. The inversion of control that dependency injection provides also enables you to refactor and test in ways that are almost unachievable without it.

It can take a little while to fully understand dependency injection, especially the intricacies of lifetime management, but once you understand the fundamentals you can apply that knowledge to any language and any framework.

• Unity
• Ninject
• Castle.Windsor

3. A Test Project

There is no reason not to have a test project as part of your solution. Regardless of how you feel about Test Driven Development (TDD) as a best practice we should all be able to agree that unit testing does provide value and is a good thing.

I encourage you to start simple: just create a test project with ONE unit test inside of it. Even if you do not have time to write tests right now, just having the project already setup will enable you to write them later. Additionally, just thinking about writing unit tests encourages you to author more testable code; so if absolutely nothing else then just use your test project as a best practices placebo!

• xUnit.net
• NUnit
• MSTest

Continue reading part 2: Three Things that all Applications SHOULD Have

Enjoy,
Tom

Log Performance in a Using Block with Common.Logging

You should be using Common.Logging to share your logger between projects.

Common.Logging is a great and lightweight way to share dependencies without requiring that you also share implementation. It is how several of my projects that use Log4Net are able to shares resources with another team that uses NLog. But that is not what I am here to talk about!

How do you log performance quickly and easily?

No, I do not mean performance counters. No, I do not mean interceptors for dependency injection. I want something far more lightweight and simplistic! What I want is the ability to simply log if too much time is spent in a specific block of code. For example...

public void MyMethod1(ILog log)

{

    // If this using block takes more than 100 milliseconds,

    // then I want it to write to my Info log. However

    // if this using block takes more than 1 second,

    // then I want it to write to my Warn log instead.

    using (log.PerfElapsedTimer("MyMethod took too long!"))

    {

        var obj = GetFromApi();

        SaveToDatabase(obj);

    }

}

The PerfElapsedTimer is just a simple little extension method that I wrote, under the hood it just wraps a Stopwatch in an IDisposable. Feel free to grab the code from below and start using it yourself.