Home » Archive by category "Testing" (Page 2)

Excuses For Not Testing

ppl-kid-044As I started my own journey into unit testing, I slowly began to realize that it was really easy to come up with reasons to NOT test my code as I was writing it, even once I understood what that was supposed to look like. The reason I think most programmers don’t unit test code, once they understand what it is they are supposed to be doing is that they don’t feel like they have permission.

To this I also answer, “How much permission do you need?”

Continue reading “Excuses For Not Testing”

NUnit Test Code Structure


There are two basic ways to structure the code you will be working on to Unit test the code in your main application using NUnit.  Arrange/Act/Assert (AAA) is what I refer to as the “Classic” method.  It has been around for as long as I’ve known about unit testing. The second method is the Given/When/Then (GWT) structure.

While both methods get the job done and both methods essentially help you structure your test, I think that the Given/When/Then structure helps us think about what we are trying to test from a more functional perspective.  Arrange/Act/Assert is more of a code based approach.

Since, in the end, what we care about is the functionality that we have coded.  I prefer Given/When/Then.  I also think GWT is better suited to Test Driven Development since in Test Driven Development, we are already in the mindset of “What is it that I’m trying to accomplish?”  And not, “What did I do and how do I test it?”


The classic method of arranging our NUnit test code conforms to the “Arrange/Act/Assert” pattern.  Using this pattern, we setup our code so that it is in the state we need it to be to perform the test.  Then we perform some distinct action on the code.  This action should exercise one and only one feature.  And then, finally we assert that the action we performed resulted in some expectation being fulfilled.

What?  Huh?

So, maybe some code will help.

Let’s assume that we have a class, Calculator, that has a method, Add:

public class Calculator
    public int Add(int a, int b)
        return a + b;

To test this class, we create another class in our test project that we will name CalculatorTest.  Well, what do we want to test in our Calculator class?  We want to test that when we add two numbers together, the proper sum comes back.  So, we’ll need a test method.  It is customary to name our methods what we are trying to test for, so we will call our test method AddShouldReturnSumOfTwoNumbers().

Following the Arrange/Act/Assert pattern, the first part of our method will create the Calculator object, then we will call the Add method, passing it two numbers, and then we will Assert that the proper result was returned.

public class CalculatorTest
    public void AddShouldReturnSumOfTwoNumbers()
        // Arrange
        var sut = new Calculator();

        // Act
        var returnValue = sut.Add(3, 7);

        // Assert
        Assert.That(returnValue, Is.EqualTo(10));


An alternate way of thinking about test is by using the Given/When/Then construct.  It essentially arranges the code in the same way, but I think it helps you think about what it is you are trying to test better.  Arrange/Act/Assert (aka AAA) tends to have you think about your code from a programmer’s perspective.  “This is what my code does.”  The Give/When/Then method thinks about the problem more from a requirements perspective.  At the end of the day what is important is that you have test around your code, so I’m not going to spend a lot of time arguing that one way is particularly better than the other.  But GWT is what I use. Since this is my post, that’s what we are going to use for the remainder of this book.

So going back to our Calculator example, what would GWT look like?

public class CalculatorTest
    public void AddShouldReturnSumOfTwoNumbers()
        // Given that we have a calculator
        var sut = new Calculator();

        // When I add 3 and 7 together
        var returnValue = sut.Add(3, 7);

        // Then the result should be 10
        Assert.That(returnValue, Is.EqualTo(10));

See, it’s all the same stuff, so whatever helps you think about what you are testing is what you should use.

NUnit & Visual Studio

Many people starting out with Unit testing get stuck when it comes to using their tools with the Visual Studio environment.  If it isn’t built in, how do we make it work with Visual Studio?  In this article I want to explore the basics of creating a unit test for NUnit and getting it running from Visual Studio.

Basic Structure

To create a unit test, the first thing you will need to do is to create an assembly with a class file to hold the code. The type of assembly you will need to create for your test to be able to run is an assembly of type "Class Library." I’m going to assume that you don’t need the details on how to create that type of project using whatever version of Visual Studio you happen to be using.

Within your new Class Library project, you should find a file named Class1.cs. For the purposes of getting started, you can just leave that file. We’ll talk about how to name your class and test later on. For now, all we want to concentrate on is the basics of what is involved in getting a basic test going and what the components of a test class are that you will repeat over and over again as you create unit test for your applications.

Before we add our first line of code, though, you will want to add references to NUnit in your code. The easiest way to do that is by using NuGet. Since I use Visual Studio 2013, all of the references for how to do things will be using Visual Studio (Premium) 2013. So, if you are using that version, you can just follow along. If not, you may need to do some translating.

From the Visual Studio menu, select "Tools" > "NuGet Package Manager" > "Manage NuGet Packages for Solution…". A window will pop up. Search for NUnit and install the package named "NUnit". There are other packages available that we will discus later on.

Alternatively, you could download NUnit directly from the NUnit site (http://nunit.org) and add a reference directly to nunit.framework.dll.


Now that you have the DLLs installed and referenced in your project, you’ll need to create a test class. For our purposes, we are going to stick with Class1.cs.

There are several things that make a class a test class. First, the class has to be attributed with the [TestFixture] attribute. Second, the methods you want to have run the test have to be attributed with the [Test] attribute and must be public. So, your minimal test class will look something like:

public class Class1
    public void MyFirstTestMethod()
        // test code here

Running Tests

Now that we have a basic test class, go ahead and compile it. We are going to try running the test next. For that we will need a test runner.

There are several ways to run NUnit test. For out purposes, we are going to use the runner that comes with NUnit. But you might also be interested in one of the alternatives. You can get a 30 day trial of ReSharper by JetBrains. ReSharper has many features, but the one I want to talk about here is the test runner. Any test you create will be immediately runnable from within Visual Studio by right clicking on an icon to the left of your code. You are presented with a menu of options including debugging your test. Believe me, this is the easiest way to debug NUnit test that I know of.

Another easy way to run NUnit test from within Visual Studio is by installing the MSTest adapter. You can get this from NuGet.

For the purposes of this article, we are going to use the test runner that comes with NUnit.

So the next thing you’ll need to do is go to NUnit.org and download and install the latest version of NUnit if you didn’t do that already to get the NUnit DLLs installed. I would suggest using the MSI installer rather than the zip file. All we want to be able to do is to run the test.

Once you’ve installed NUnit, there should be a menu option "NUnit" that you can click. This should bring up the GUI runner.


Use the "File" -> "Open" to navigate to the "bin" directory of your NUnit test DLL project and open the DLL. You should see a screen that looks something like this:


Click the "Run" button to run your test. You should get a green progress bar under the "Run" button and a check box over the icons in the tree on the left indicating that all of the test succeeded.

"Wait?!", you say, "I didn’t test anything, how did they succeed?"

You are right. A test succeeds if it doesn’t fail. Later on this will impact how we structure our test. So keep this in mind.

One of the nice things about the NUnit GUI runner is that you can keep this up while you work on your tests. By default, the system shadow copies the DLL so that you can compile the DLL in your project. When the NUnit GUI runner sees that the file has changed, it will reload it so that it is always running whatever version you recently compiled. You can change this behavior, if you really feel the need to, by navigating to "Tools" -> "Settings…"

Debugging Tests

As with all things related to code, eventually you will need to debug your test. To do this using the the tools that come with NUnit, do the following.

Right click on the project in Solution Explorer that represents your test project. From the resulting menu, select "Properties." In the resulting window, select the "Debug" tab from the left-hand side of the window.


You will want to select "Start external program" and point it to the UNnit runner that got installed when you installed NUnit.

Now, whenever you run this project, with or without the debugger, NUnit will start up. Note: there is no reason to pass parameters telling it what DLL you want to run because it will load the last DLL it had up. But, if you wanted to do that, you could pass the location of the DLL as a parameter to the GUI runner. There are other parameters you can us. Check the documentation for the version of NUnit you are using for the specifics.

If you are running .NET 4.x, you’ll want to go to the location in your file system where NUnit.exe lives and find the NUnit.exe.config file. Find the startup element (<startup> …. </startup>) and place this line in between the open and close startup tags:

<supportedRuntime version="4.0" />

If you miss this step, you won’t be able to debug your 4.0 code. Alternatively, you can just set your project to use .NET 3.5.

So, let’s give it a try.

First, put some code in the test method you just created. For our purposes, we’ll just put in a console writeline so we have somplace to put a breakpoint.

public void MyFirstTestMethod()
    Console.WriteLine("Inside MyFirstTestMethod");

Next set a breakpoint on the Console.WriteLine method and then run your project with the debugger.

Once NUnit loads the DLL, click the "Run" button in NUnit. If everything is setup correctly, you should stop on the breakpoint you set.


You may have noticed that we put several Console.WriteLines() in our code but they aren’t displaying anywhere. So, where did they go? How can we see them?

By default the "Text Output" tab displays all of the Console.WriteLine() messages as well as all of the test results. If all you care to see is the test results, you should select the "Errors and Failures" tab. Personally, I prefer to work in the "Text Output" tab and I suggest that you do the same.

Not The Only Way

This isn’t the only way to get NUnit & Visual Studio working together.  You could also purchase the ReSharper plugin which has many other features.  But one of the ones I use on a regular basis is the NUnit integration.

You could also use the NUnit test Adapter to make NUnit work with the Visual Studio test engine.  But personally, I don’t like the way the test render using that and I’d much rather use the GUI viewer I’ve discussed in this article.  So, if you want to integrate NUnit & Visual Studio for free, what I’ve outline above is the best way to do it.

ASP.NET Server Performance Testing


This happened a couple of years ago, but it is still relevant because I know of at least one place where it is still happening even though Microsoft has fixed the issue that initially caused this hack to be put in place in the first place.

Problem In Production – Oh NO!

Here’s the problem we were seeing.  We had several large PDF files that the client wanted to put up on the site so that their customers could download them.  The problem that we were seeing is that even though the site worked fine under development and QA, the site seemed to consume a lot of memory under load.

Another symptoms we saw was that the file download took a lot of time to start, or timed out completely.  But the main issue was the memory because when the memory was consumed, the site would restart, and because it was a worker process crash that caused it, the restart took the site down.  This is not something you want to see happen when you are working with a client with world wide exposure.  A client who, if I told you the name, I’m sure you would recognize.

In fact, it was the site not responding, or crashing, that first alerted us to the problem.  So, as soon as we knew the site wasn’t responding, I’d log onto the server and fire up task manager to see what was going on.

Server Management Tip

One of the things I did early on managing the servers, is that I set up an entirely separate app pool for each of the web sites we are hosting.  This way, we can monitor the memory and CPU activity of each one independently.  For those of you who are interested, the way to make the pool name show up in task manager is to run the pool in ApplicationPoolIdentity, a setting you can get to through “Advanced Settings…”  If you are only hosting one site, you shouldn’t need to do this, but in my case, with multiple sites, this told me a lot about what was going on with the sites and ultimately helped me track down what the problem was.

By the way, you should always run each of your sites under a separate application pool so that when one site is having trouble, every site on your server doesn’t have trouble.  Imagine having an issue and not even knowing for sure which site was causing the trouble.  It’s bad enough not knowing what page is causing the problem.

It Is a Memory Issue.  Now What?

OK.  So, I could see the memory increasing as soon as the site came back up.  So, now to try to track down what was causing memory issues.

I tried various things along the way, none of them shed any light at all on the problem.  I even got dotMemory from JetBrains to see if I could find anything.  A memory leak maybe?  No, none of my code had even a small leak.

The Fix Discovered

And then I finally stumbled on the issue.  I can’t remember what it was that we installed that needed this, but what it did was change our web.config file so that it had a section in it that looks like this:

... lots of other configuration stuff ...
    <modules runAllManagedModulesForAllRequests="true">

What that causes IIS to do is to run ALL of your web request through ALL of your .NET modules.  Why is this a problem you ask?  Because it even runs all of your images, css, javascript and other static content.  This isn’t normally a huge problem because most of that stuff is relatively small. But, when you try to run a be PDF through that pipeline, you’ll run out of memory because, and this is the major issue here, because the whole file has to be loaded into memory on the server before it can be sent on to the web browser to download.

Make sure that runAllManagedModulesForAllRequest is either set to false, or doesn’t exist in your web.config file.  If you need it to be turned on for some valid reason that I am not thinking of, at least put your static files on another site where this can be turned off.

Moral Of The Story

Now, the question that we should be asking now that we’ve figured it all out is, why wasn’t this caught earlier?  When a site goes up, isn’t all of the functionality, including all of the links to all of the images, files to download, and other pages on the site and off the site supposed to be tested?

Yes, of course they are, but if you haven’t at least written down where all of this is, if you don’t have a systematic way of testing EVERYTHING, you WILL end up with these kind of errors once you put the site live.  This is to say nothing of load testing along the way.  This can all be prevented.

Is Your Architecture Crippling Your Unit Testing?

Last week I wrote a post that talked about Unit Testing and the need to make sure you are only testing one particular unit of code at a time.  The post was well received.  But I am surprised that no one commented on the glaring hole I left in the post.

In that post, I said:

Continue reading “Is Your Architecture Crippling Your Unit Testing?”