Writing Output from MSTest

Unit testing can sometimes throw up unexpected issues that are entirely concerned with the unit tests and not the application under test. Recently I’ve been having issues with DateTime formats affecting the results of the unit tests: the format of the DateTime was different on the build server than it was on my local machine. The stored procedure could not be altered (because reasons*). The datetime formats on both SQL and Windows were identical to my machine, and running the test itself on the build box caused the test to go green, so clearly there was something funky going on in the build process. SO I needed to find a way of logging the values during the process to verify where the issue was. And, as luck would have it, MSTest has such a method to help you. First create a private instance of the TestContext object in the TestClass, then you create a public property.

    public class PartitionMaintenanceDateTime2

        private TestContext testContextInstance;

        public TestContext TestContext
                return testContextInstance;
                testContextInstance = value;

Then you can use Test.Context.WriteLine to output to the test result a message that helped me identify where the pain point was and how to format. Code snippet is below from one of my tests where I used the WriteLine to log the format of thedatetime pre and post parsing.

                for (int i = 0; i < RangeValueBefore.Count; i++)
                    DateTime dt = RangeValueBefore[i];
                    TestContext.WriteLine("Format pre-parsing " + Convert.ToString(dt) + ". Am attempting to change format to " + dateFormat + ".");
                    string m = dt.ToString(dateFormat);
                    TestContext.WriteLine("Format post-parsing " + Convert.ToString(m));
                    RangeValueBefore[i] = DateTime.Parse(m);
            catch (Exception e)
                throw e;

So now on the output of a test I run locally, and on the Test Results pane on VSTS, I can see what as going on in the build. This is really usefully when trying to fix tests that are failing for odd reasons.


*Just for context: The stored procedure itself was not under test: it was a helper stored procedure. When I looked at the stored procedure I wasn’t actually returning a DateTime: I was returning a syscolumn that was of type sysname. And the type of this column could contain data that as represented as an int or datetime, or in fact any data type you can partition on. But whilst I wanted to make sure that the value returned was a valid DateTime (the whole purpose of the test), the stored procedure may also need to return ints etc for any other tests. Testing is hard for sure, especially when you have to go through the trouble of creating stored procedures just to verify that other stored procedures are doing what they are intended to do, but it is certainly worth the peace of mind.

Author: Richie Lee

Full time computer guy, part time runner. Full time Dad, part time blogger. Knows a thing or two about Pokémon. Knows too much about SQL Agent. Writer of fractured sentences. Maker of the best damn macaroni cheese you've ever tasted.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s