Either download from the extension manager by searching OpenWithTest or go to the project page here.

Summary

Open with Test is a Visual Studio extension which serves one simple task: To always open your test files and implementation files together.

Details

When writing unit tested applications (especially while practicing TDD) you will often open an implementation file (i.e SomeClass.cs) followed by the test file(i.e. SomeClassTests.cs).  This extension makes this a one step process.

It works by detecting when you open a new file and attempting to find via convention the test file. It assumes that you create one test file per class.  So, if you create a class called Car in the file Car.cs then you will have a test file named CarTests.cs which tests the car class.

Currently, only C# (.cs) files are supported but I plan to expand this to other files types soon.

Configuration

Out of the box, this extension will assume a file is a test file if it ends with the suffix Test,Tests, Fact or Facts.  However, this can be configured.  To change these go to Tools -> Options -> Open With Test and you will see this screen:

Feedback

I would love to get feedback about features or suggestion so please feel free to leave a comment on this blog post or start a discussion post on the Visual Studio Gallery page.

A test case should be like a simple short story.  The characters are introduced, action/conflict occurs and then resolution takes place (sometimes with a moral).  This (kind of) corresponds to the 3 steps of a unit test: arrange, act and assert.  You arrange and setup what you need for your test to run, you perform the action that you are trying to test and then you assert the results. The issue I find is that a coder, in attempting to apply DRY to his test cases, will abstract away all of the arrange step into a function often with a name like SetupExpectations or just Setup.  This goes against the point of a test case. A test case needs to be concise and tell me everything I need to know about how that one bit of functionality works. I don’t want to jump around the test class trying to read one test case. To me, this is like reading a book that says, “If you want to learn about the characters in this book please open this other book.”  This doesn’t stop you from understanding the test, but it slows you down…and is just annoying.

That is why I will come out and say do not apply DRY haphazardly to test cases.

A test case should be like a simple short story.  The characters are introduced, action/conflict occurs and then resolution takes place (sometimes with a moral).  This (kind of) corresponds to the 3 steps of a unit test: arrange, act and assert.  You arrange and setup what you need for your test to run, you perform the action that you are trying to test and then you assert the results. The issue I find is that a coder, in attempting to apply DRY to his test cases, will abstract away all of the arrange step into a function often with a name like SetupExpectations or just Setup.  This goes against the point of a test case. A test case needs to be concise and tell me everything I need to know about how that one bit of functionality works. I don’t want to jump around the test class trying to read one test case. To me, this is like reading a book that says, “If you want to learn about the characters in this book please open this other book.”  This doesn’t stop you from understanding the test, but it slows you down…and is just annoying.

That is why I will come out and say do not apply DRY haphazardly to test cases.

A test case should be like a simple short story.  The characters are introduced, action/conflict occurs and then resolution takes place (sometimes with a moral).  This (kind of) corresponds to the 3 steps of a unit test: arrange, act and assert.  You arrange and setup what you need for your test to run, you perform the action that you are trying to test and then you assert the results. The issue I find is that a coder, in attempting to apply DRY to his test cases, will abstract away all of the arrange step into a function often with a name like SetupExpectations or just Setup.  This goes against the point of a test case. A test case needs to be concise and tell me everything I need to know about how that one bit of functionality works. I don’t want to jump around the test class trying to read one test case. To me, this is like reading a book that says, “If you want to learn about the characters in this book please open this other book.”  This doesn’t stop you from understanding the test, but it slows you down…and is just annoying.

That is why I will come out and say do not apply DRY haphazardly to test cases.

156.27.1.2, 156.*.*.*, 127.0.0.*

Where the * acts as a wild card and each comma-separated IP format is matched against the incoming IP address. The code’s intended behavior is that specifying no IP address formats in the config would mean that no IP addresses would match the format.  We noticed that this wasn’t holding true.  We went to examine the code that was performing the matching (which none of us had written and sadly has NO test cases around it).  The code boiled down to something like this:

   1: bool DoesIPMatchIPFormat(string incomingIpAddress, string ipFormatsFromConfig)

   2: {

   3:     foreach(var ipFormat in ipFormatsFromConfig.Split(','))

   4:     {

   5:         Regex re = ConvertFormatIntoRegex(ipFormat);

   6:         if(rs.Match(incomingIpAddress).Success) return true;

   7:     }

   8: }

Where ipFormatsFromConfig is the ip range of formats shown above separated by “,” or an empty string if no formats are given. On first glance we all were confused by why this didn’t work and then as we looked into it we realized we had made some incorrect assumptions.

First, we assumed that “”.Split(‘,’) would return a zero element array.  This assumption is false. It returns a 1 element array containing the empty string. 

After we learned this we encountered our second assumption.  We assumed that a regular expression whose pattern was an empty string would not match anything. (ConvertFormatIntoRegex returned just that).  This assumption is also false.  After learning the true behavior, it makes sense why it behaves this way.  (A DFA with only one state must accept every input. )

Our assumptions about the “correct” behavior of functions reflect similar mistakes made by all programmers; assuming that you don’t make these kinds of assumptions is a very dangerous way to program and reinforces the importance of unit testing.

156.27.1.2, 156.*.*.*, 127.0.0.*

Where the * acts as a wild card and each comma-separated IP format is matched against the incoming IP address. The code’s intended behavior is that specifying no IP address formats in the config would mean that no IP addresses would match the format.  We noticed that this wasn’t holding true.  We went to examine the code that was performing the matching (which none of us had written and sadly has NO test cases around it).  The code boiled down to something like this:

   1: bool DoesIPMatchIPFormat(string incomingIpAddress, string ipFormatsFromConfig)

   2: {

   3:     foreach(var ipFormat in ipFormatsFromConfig.Split(','))

   4:     {

   5:         Regex re = ConvertFormatIntoRegex(ipFormat);

   6:         if(rs.Match(incomingIpAddress).Success) return true;

   7:     }

   8: }

Where ipFormatsFromConfig is the ip range of formats shown above separated by “,” or an empty string if no formats are given. On first glance we all were confused by why this didn’t work and then as we looked into it we realized we had made some incorrect assumptions.

First, we assumed that “”.Split(‘,’) would return a zero element array.  This assumption is false. It returns a 1 element array containing the empty string. 

After we learned this we encountered our second assumption.  We assumed that a regular expression whose pattern was an empty string would not match anything. (ConvertFormatIntoRegex returned just that).  This assumption is also false.  After learning the true behavior, it makes sense why it behaves this way.  (A DFA with only one state must accept every input. )

Our assumptions about the “correct” behavior of functions reflect similar mistakes made by all programmers; assuming that you don’t make these kinds of assumptions is a very dangerous way to program and reinforces the importance of unit testing.