In software development, the struggle to be disciplined with our best practices never ends. It’s easy to forget what we’re supposed to do, and so tempting to take shortcuts when we do remember.
On my team, we have a long list of standards and best practices. We have agreed on naming conventions, agreed to treat warnings as errors, agreed to use Code Contracts, agreed on which Code Analysis warnings we’ll heed, etc., etc.. It’s tough to remember them all when setting up a new project.
Enter Visual Studio Project Templates!
In this series of posts, I’ll show how we’re using a Project Template to create unit-testing projects that adhere to our standards and best practices. When we’re done, we’ll have a Visual Studio 2012 solution that creates the Project Template and packages it for distribution as a .VSIX.
Once the Template is installed, creating a unit-testing project that follows all the rules is just as easy as creating one that does not. Let's hope that encourages everyone to do the right thing!
To keep things manageable, I’ll pare down our objectives to these, all based on our standards in real life.
- The unit-testing assembly must be named after the assembly it tests, but with “.Test” in the name. For example, Fws.Common.dll’s unit-testing assembly would be called Fws.Common.Test.dll.
- Assembly names mimic our directory tree. Fws.Common.Test.dll might be in C:\Software\Fws\Common\Test. The C:\Software part should not be relied on; relative paths should be used.
- An assembly's default namespace equals the name of the assembly (e.g., Fws.Common.Test).
- The new assembly must be signed with our standard key, which is in a separate directory. The key file should be included in the project as a link, not copied.
- We will use warning level 4, and treat warnings as errors.
In the next post, we will create a Project Template with no enhancements, just to see what Visual Studio gives us for free. We’ll observe the deficiencies of the result, and correct them in the posts that follow.