Read this great article about unit testing wisdoms, thought its worth sharing.

The Way of Testivus

• If you write code, write tests.
• Don’t get stuck on unit testing dogma.
• Embrace unit testing karma.
• Think of code and test as one.
• The test is more important than the unit.
• The best time to test is when the code is fresh.
• Tests not run waste away.
• An imperfect test today is better than a perfect test someday.
• An ugly test is better than no test.
• Sometimes, the test justifies the means.
• Only fools use no tools.
• Good tests fail.

RWendi

Yesterday, I found that my laptop was infected by a virus. I was a bit surprised by it, because, well, it’s my first time. I always try to keep my computer pretty clean whenever I’m using it, and I’m not sure where and how I got this virus. The virus is undetectable with AVG Free, which I have installed in my machine. This can mean 3 things: The virus is relatively new, the virus is not a BIG threat, and lastly AVG Free sucks. Anyway, the virus has the following symptoms:

• Internet explorer title bar has “[--Hacked by ROCKSTREET—] @InF” message.
• Your computer keeps on prompting you with “Drive was not found, please insert disk at location” dialog.

As you can see from the symptoms, the virus is not very threatening. The second symptom can be a bit worrying, but I’m finding that all of my drives can be found and work with no problem. Thus that dialog window is probably a bogus dialog window. After gathering some more information from the net, finally found a way to remove the virus, here is how:

• Go to “Start Menu” and then “Run”. In the dialog box type “msconfig” and click “Ok”.
• Select the “Startup” tab, and un-tick rockstreet entry. Click “Apply” –> “Ok” –> “Exit without Restart”.
• Go to “c:\windows” and the root of every drive that you have (e.g. “c:\”, “d:\”), and then delete the “rockstreet.dll.vbs” file.
• Go to the following registry key “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run”, and delete the load key.
• Go to the following registry key “HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main”, and clear up the “Window Title” value key.
• Restart your machine.

Hope this helps in removing the virus if your computer is having the same problem.

RWendi

Working as a programmer I feel like that I’m lacking of business skills. Whether that be my business knowledge, marketing, nor management skills, I have none of them. I think I focused too much on how to be better in what I do and completely forgotten of my long term goal. It’s always been my dream to run my own business, and I think I will have better chance of succeeding if I come well prepared.

I think there are many aspects of business that needs to be explored, such as:

• Running your business.
• Managing your employee/team.
• Marketing your product/services
• Leadership
• Sales/Revenue strategy.
• Others.

Those are pretty much gray areas for me. I have no experience in any of those business aspects, nor do I have the knowledge. I’ve decided it’s time to do something about it, so that when the time comes to run my business, I wouldn’t be a complete idiot and had no idea what I’m doing. My approach to getting my business skills hone up is simple, Books and Blogs. From today I’ll start reading more and more business related books and blogs. Hopefully they will help me to gain some business skills as they do with my programming skills.

RWendi

The last 2 weeks have been one of the most fun times working for Docscorp. The team were given the chance to redesign our comparison model to be a better one. At the current state, the model is one big giant blob of procedural functions which are contained in …. 2 CLASSES. Yep that’s right 2 classes. (Now you know how bad it is). Our job was basically to transform these 2 classes into a model that is much more object oriented.

I spent some times to skim through all the functions of the 2 classes. I realized that all the logics are already solid, its just that the code are not as “organized” as it should be. Or in other words, redesigning the current model means One BIG refactoring job needs to be applied to the 2 classes.

I decided to take a stab on it and started refactoring the classes. After a few days, I came up with a good clean model of how it should be done. While refactoring, I realized that all I’m doing is just applying a couple of programming principles to those 2 classes. These principles are:

• Single Responsibility Principle (SRP).
• Don’t Repeat Yourself (DRY).
• Keep It Simple Stupid (KISS).

Yep, those are the only principles that helped me transform/refactor 2 giant procedural classes to be a modular object oriented model.

I think those should be the basis of your decision of when to refactor your code. If you find that you’re repeating yourself or writing the same/similar logic, then it warrants to refactor your code. If you find that your logic/algorithm gets too complicated, it’s time to break it down to make it simpler (doesn’t mean that you have to change your logic). Lastly if you find your code is doing to much or having to much responsibility, it’s time to refactor it out (I know by definition SRP is a class thing, but I think the same logic can be applied to functions).

You can always take things further and apply more programming principles to your code. But these three principles is a must in order to achieve a reasonable clean code. If you apply these three rules in your day to day code, I’m sure overtime you’ll find that your code will be a lot cleaner and much more maintainable. Thus, don’t be afraid to apply these rules to refactor your code.

RWendi

Visual Studio 2008 comes with a unit testing tool, MSTest. The coolest thing about MSTools is that it integrates so well with Visual Studio. Every time you build your solution, Visual Studio will automatically run your test projects and display the results in a nice graphical user interface (similar to NUnit’s one). I’ve been using MSTest for my side projects, until I found out that MSTest is not supported Visual Studio Express, which I have installed in my MSI Wind. Because of this limitation, I had to resort back to the good old NUnit.

After using NUnit again, I really missed MSTest integration with Visual Studio. NUnit provides a very minimal integration with Visual Studio, which requires you to create an external tool that points out to the NUnit console. When you run the NUnit tool, it will spit out the results into your Visual Studio’s output window. The simplistic approach works, but the problem with this is that I have to run it manually each time I run my build. It would be ideal to just have this automatically run each time we build our solution. Luckily, this can be automated by using Visual Studio macro and post build event. Here is how you do it.

Creating NUnit As A Visual Studio External Tool

First we need to create NUnit as a visual studio external tool. To do this, in Visual Studio, go to Tools > External Tools. You will be prompted with a form, in which you can manage all of the available external tools. Click on the Add button and fill in the form as follows.

You should fill in your form exactly as above, except for the Title field (if you wish to have different name) and the command field. The command field is the path to your NUnit console runner. Click the Ok button to create the external tool. Now that you have created it, if you go to Tools menu in Visual Studio, you will see NUnit in one of the available external tools. When you run the NUnit external tool, it will run NUnit through command line, and display it in your Visual Studio output window.

NOTE: the above will make NUnit runs all of the tests in the current active project. Thus make sure your active project is your test projects when running the tools. You can do this by having your test as your active file in Visual Studio when compiling. You can make it not to be bounded by your current active project by; hardcoding the arguments value to be your test dll and the inital directory value to be the location of your test dll. But keep in mind that the tool is not project/solution specific. That is, if you open up a different solution, it will still run the hardcoded value.

Automating NUnit Integration To Run After Compile

Now that you have the NUni integration set up, its time to make it run automatically after each compile. Here’s how you do it:

• In Visual Studio go to Tools > Macros > Macros IDE.
• This will bring up a the Macros IDE.
• On the left hand side there should be a “Project Explorer” panel.
• In the Project Explorer panel, double click on EnvironmentEvents module.
• Insert the following code in the module.

Private Sub BuildEvents_OnBuildDone(ByVal Scope As EnvDTE.vsBuildScope, ByVal Action As EnvDTE.vsBuildAction) Handles BuildEvents.OnBuildDone

    DTE.ExecuteCommand("Tools.ExternalCommand1")

End Sub

As you can see that the above custom macro tries to run an external tool by its order. Thus depending on where you put your NUnit tool, you might want to change the parameter of right number based on the order of your NUnit tool. For example, if your NUnit is the third external tool, you can change the macro to this: DTE.ExecuteCommand(“Tools.ExternalCommand3”).

Debuging Your NUnit Tests.

Now that you have everything set up, how can one debug their NUnit tests? Surely you want to debug your tests once it fails. Here’s how you do it:

• Right click on your test project and select "properties”.
• On the right hand side, click on the Debug tab.
• Change the start action from “Start Project” to “Start External Program”.
• Insert the path to your NUnit GUI runner as your External Program.
• In the Start Option section, insert your test dll, as your command line args, followed by “ /run”. For example: “tests.dll /run”.
• Lastly set your working directory to the path of your test dll.
• Your form should look something like this.

With this configuration set up, whenever you run your solution (don’t forget to set your test project as your Start Up project), this will run NUnit’s GUI runner to run your tests. Moreover, Visual Studio will automatically attach the debugger to the NUnit’s GUI runner process. This means that you can start debugging by putting breakpoints in your test code.

Wait a minute, isn’t this another way of automatically running NUnit after compile? Yes it is. So why mentioning the “External tool” method? Well the problem with running NUnit as external program is that, you have to always run your solution (F5) and set your test project as your start-up project. Doing it as an external tool, you can just build your solution and it runs your test automatically. Moreover, I find that NUnit runs much faster in the “External tool” method.

Hope you find this useful. Now write some TESTS!

RWendi