The Devlineator

So I found a problem that the project I am working on had a bunch of nUnit tests that needed converted to MSTest and I really didn’t want to do a find replace on all the keywords so I did the following.

using Microsoft.VisualStudio.TestTools.UnitTesting;
using TestFixture = Microsoft.VisualStudio.TestTools.UnitTesting.TestClassAttribute;
using Test = Microsoft.VisualStudio.TestTools.UnitTesting.TestMethodAttribute;
using TearDown = Microsoft.VisualStudio.TestTools.UnitTesting.TestCleanupAttribute;
using SetUp = Microsoft.VisualStudio.TestTools.UnitTesting.TestInitializeAttribute;
using TestFixtureTearDown = Microsoft.VisualStudio.TestTools.UnitTesting.ClassCleanupAttribute;
using TestFixtureSetUp = Microsoft.VisualStudio.TestTools.UnitTesting.ClassInitializeAttribute;
using Explicit = Microsoft.VisualStudio.TestTools.UnitTesting.IgnoreAttribute;

Then you just paste this into the using of your test file, and remove your nUnit references. Bob’s your uncle converted.

Productivity, Testing unit tests, nunit, mstest

When talking to a friend of mine we had the idea to do a blog series over C# functions that might help people if they don?t know about them. This will be categorized so you can keep up on it, and it will be once a week on Mondays. First I was going to start with ?continue?. Nest ifs inside a loop cause major performance issues in most applications but there are a few ways to avoid this. The MSDN definition of continue is ?The continue statement passes control to the next iteration of the enclosing iteration statement in which it appears.? . Here is the code snippet that we are going to clean up. ?Caution the following code is not suitable for young viewers or those that are faint of heart.?

IEnumerable<ReflectionParameter> test = new List<ReflectionParameter>();

            foreach (var parameter in test)
            {
                if (parameter != null)
                {
                    parameter.MethodName = "Something";
                    if (parameter.children != null)
                    {
                        foreach (var child in parameter.children)
                        {
                            if (child.MethodName == null)
                            {
                                child.MethodName = "Something";
                            }
                        }
                    }
                }
            }

I know right? We can clean this up by inverting the first if to a continue statement.

IEnumerable<ReflectionParameter> test = new List<ReflectionParameter>();

            foreach (var parameter in test)
            {
                if (parameter == null) continue;
                parameter.MethodName = "Something";
                    if (parameter.children != null)
                    {
                        foreach (var child in parameter.children)
                        {
                            if (child.MethodName == null)
                            {
                                child.MethodName = "Something";
                            }
                        }
                     }
            }

We can still clean this up by inverting the children check to a continue statement.

IEnumerable<ReflectionParameter> test = new List<ReflectionParameter>();

            foreach (var parameter in test)
            {
                if (parameter == null) continue;
                parameter.MethodName = "Something";
                if (parameter.children == null) continue;
                foreach (var child in parameter.children)
                {
                    if (child.MethodName == null)
                    {
                        child.MethodName = "Something";
                    }
                }
            }

We can also do this to the if inside the second for each loop.

IEnumerable<ReflectionParameter> test = new List<ReflectionParameter>();

            foreach (var parameter in test)
            {
                if (parameter == null) continue;
                parameter.MethodName = "Something";
                if (parameter.children == null) continue;
                foreach (var child in parameter.children)
                {
                    if (child.MethodName != null) continue;
                    child.MethodName = "Something";
                }
            }

This is a much cleaner section of code but is not great. It still has a nested for each loop. which makes my insides scream, but we will attack that sort of nesting next week.

.NET, Productivity, C# Helpful Functions

I started coding in C# about a year ago and almost immediately found that once I had completed a project I wanted to go back and streamline and improve it. When time allowed I started trying to do this and found that the code was very hard to verify functionality. I also found that some of my design choices were pretty novice, due to that the code was very hard to enhance. 
I got introduced to the idea of test driven development by a good friend Rob Tennyson. He presented on the topic at the Tyson Foods internal .NET user group. This peaked my interest for two reasons. One, It would allow for avoiding the novice mistakes in design and class layout. Two, it would allow for my code to have automated verification of functionality.
I set out to work TDD into my everyday process and hit several brick walls.
1. You end up making things public for testing that should not be otherwise, or putting test code into the finished product (neither is a workable solution in my book). I am using NUnit and I didn't want to have a reference to a testing package in my production code. Adding a dependency to the production code that other developers will have to deal with was not my idea of a stable codebase.
2. Being a beginner in TDD as well as C# I didn't know what I didn't know so by that lack of code and language knowledge I repeated some novice mistakes in design. Not as many as before but still a few. Some would argue that I gained knowledge and that is why I see those bottlenecks and design issues more clearly and to that my only reply is "yeah prolly".
3. Abstraction is a premium but sometimes too much work. I write a lot of small applications, an editor here, a website there. While I do work to abstract a lot of my code and provide interfaces in the right places for a small application putting in the level of seams needed for proper TDD would be building an elevator in an outhouse.
4. I found it increasingly difficult to find answers in my hunt for TDD utopia. I read several books on the subject and found that I was more often than not provided with contradictory rules to apply, or methods to use. Microsoft's "Test-Driven Development in Microsoft .NET" by James W. Newkirk and Alexei A. Vorontsov gave great baseline examples and presented the basics of TDD very well, however it fails to provide good solid base for TDD in the real world. The application that they base a lot of their examples around ignores some fairly large aspects of the TDD mindset like separation of integration testing and design testing.

With the miles behind me and a TDD utopia still nowhere in sight I have found several good ideas.

1. Kent Beck's TDD by Example is a great resource for TDD on the intermediate to advanced level.

2. Not everything needs to be designed using TDD, some things are just too trivial.

3. TDD is a design pattern, and it should be used as such. If you want automated testing use automated tests, but if you want TDD programs before one line of code is written have a test list and priority assigned to them.

I am working on a TDD project currently with Jay Smith and Rob Tennyson to write a checkers application using only TDD and having no UI or Data Layer. Building Logic first, then the UI, and finally adding a data layer to detail how to handle those real world integration concerns.

Just Remember Code like you have to support it.

C#, .NET, Productivity, Unit Testing, Design Patterns

So I know there are probably places to find this out there but I wanted to throw this out there because I had a hard time finding it.

Batch files are used for a lot of things for deployments and normally you would have to some these from the window explorer instead of in VS. I say why leave VS if you don?t have to?

Go to Tools ? > External Tools

This will open a new dialog that you will have some items in or not.

Hit Add and type in the name you want it to appear on your right click menu as, Navigate to or type in the path to cmd.exe, and type /K to the Arguments then with the cursor still in arguments click the arrow to the right and select Item Path. Click the arrow to the right of Initial Directory and select Item Directory. Make sure to click the ?Use Output window? option. Your finished dialog should look something like the above picture. Hit apply and OK.

Remember the count of the new item as it will be needed later. For my example this would be 6.

Then to put this on your right click menu. Right click the grey space near a toolbar to get the toolbar customize menu and click customize.

This should open a new dialog like the one below.

Click Context Menus. This will add a bar to the toolbar temporarily. Go to the Commands tab on the dialog and scroll down to tools. In the pain to the right select the External Tool with the number that you wrote down / remembered from earlier. For me this was 6.

Click and Drag the External Command you selected to the toolbar that was added. It needs to go under Project and Solution Context Menus, and then under Item. the position under item is just preference on where you want it in the right click menu.

The name will not be External Command #, it will replace that with the name you typed in.

Then when you have a batch file you can right click it, and choose your new option and it will run it, but output into the output window of Visual Studio without having to leave the IDE.

Enjoy.

Visual Studio 2008, Productivity