JavaScript, Unit Test, Visual Studio and Build Machine Integration

Today I will write a short post about JavaScript and unit testing. I heard a lot of .NET developers that they didn’t wrote code for JavaScript because is not supported by Visual Studio, is complicated to run it on the build machine or they don’t have time.

Guys, I have news for you, Visual Studio 2012 supports unit tests for JavaScript, even Visual Studio 2010. You can run them almost like a normal unit test for C# without needing to install anything. The JavaScript unit tests are so smart that are integrated in a way that you don’t need to change/install anything on your build machine – you even receive the standard message notification when a unit test fail. You don’t have time for them – I will not comment this, definition of DONE is wrong for those developers.

When I need to write unit tests for JavaScript code I usually prefer qunit. Why? Because in combination with a small NuGet package called NQunit you can make magic.

qunit give you the possibility to write and run JavaScript unit tests. This is a simple testing framework. The output of running unit tests is a XML that can be parsed, used by build machine or any other machine. More about qunit:

http://vunvulearadu.blogspot.ro/2012/10/how-to-write-unit-test-in-javascript.html

http://vunvulearadu.blogspot.ro/2012/10/new-unit-tests-features-of-visual.html

NQunit makes the integration between classic unit tests for C# and JavaScript code. Using this package you will have the possibility to run unit tests written in JavaScript like normal unit tests. I prefer it because you can use it with success in Visual Studio 2010 also, not only in Visual Studio 2012. One nice feature of this package is the way is integrated with the build machine. Because this package runs normal unit tests you don’t have to change anything on the build machine or to install something on developers’ machine.

The secret of NQunit is the way how it run the tests. He takes from the output folder of the HTML files that were added and run them in a browser. For each of them, he capture the XML that is generated after the test run. The XML that is generated by qunit contains the summary of the test result and can be used to get all the information that are needed. At the end, NQunit will close the browser.

public static IEnumerable<QUnitTest> GetTests(params string[] filesToTest)

Using this method you can specific all the files you want to test. Don’t worry, when you will start to use NQunit you will see that there is a great sample on NQUnit that is preconfigured.

Hints before you start:

   Don’t run the tests from ReSharper, ReSharper don’t run the tests as you expect – because the way how each session of tests runs and access the rest of the output build.

               If more then one unit test from JavaScript fails, you will only receive information related to that only one unit-tests – this can be fixed writing some C# code, but I can live with it.

               If you have JavaScript code then write some Unit Tests.

I started to use this NuGet package one year ago and it works great. For more information about this great package:

http://nuget.org/packages/NQUnit/

http://robdmoore.id.au/blog/2011/03/13/nqunit-javascript-testing-within-net-ci/

Read More

How to write unit-tests for async methods

All developer that works with .NET heard about Task, async, await – Task Parallel Library (TPL). Great library when we need to write code that runs in parallel.
With TPL, writing code that run in parallel is pretty simple. This is great, but of course, all code that run in parallel need to be tested also – unit tests. Do you know how you need to write unit tests for async calls?
I so pretty strange way of unit tests for async methods. Some of them were ugly and complicated. Why? Because the unit test method is a sync one and there we try to run and wait a response from an async call. This is why we can end up with something like this:

        [TestMethod]
        public void MoveFile_ExistingFile_ResultsFileMovedAndOriginalFileDeleted()
        {                        
            StorageFolder destinationFolder = null;
                        
            Task.Run(() => destinationFolder = 
                                CreateFolderAsync(_originalFolder).Result)
                                  .Wait();
            
            var fileToMove = StorageHelper.CreateFile(_originalFolder,FileName);

            Task.Run(() =>  _fileManipulator.MoveFileAsync(fileToMove, destinationFolder))
                                  .Wait();

            Assert.IsTrue(_fileManipulator.Exist(destinationFolder, FileName));
            Assert.IsFalse(_fileManipulator.Exist(_originalFolder, FileName));
        }   

or

        private void SaveContent(byte[] originalContent)
        {
            Task saveTask = Task.Run(() => _applicationFileManager
                                  .SaveAsync(FileName, originalContent));
            saveTask.Wait();

        }

What do you thing? Do you like to have in the unit tests calls to Task.Run(). Personal I don’t like this and for me is a big smell. Something we are doing wrong, we are missing something.
What we are missing is the way we are writing the unit test method. By default, when we are wring a unit test we define the unit test method in this way:

[TestMethod]
public void SomeTest() { }

This is okay for testing a sync call. But when testing async call we have more option. It would be nice to be able to have our test method as an async method. In this way we don’t need to call Task.Run().
The reality is that we can define a test method like this:

[TestMethod]
public async Task SomeTest() { }

Doing this we can call our async method as a normal method and test accordingly.

        [TestMethod]
        public async Task MoveFile_ExistingFile_ResultsFileMovedAndOriginalFileDeleted()
        {                      
            StorageFolder destinationFolder = null;
                     
           destinationFolder = await CreateFolderAsync(_originalFolder)
         
            var fileToMove = StorageHelper.CreateFile(_originalFolder,FileName);

            await _fileManipulator.MoveFileAsync(fileToMove, destinationFolder);

            Assert.IsTrue(_fileManipulator.Exist(destinationFolder, FileName));
            Assert.IsFalse(_fileManipulator.Exist(_originalFolder, FileName));
        }

This feature works only on Visual Studio 2012.
On Visual Studio 2010 we need to install a NuGet package called AsyncUnitTests-MSTest. This will allow us to use async and await in our unit test. We will need to replace the TestClass attribute with AsyncTestClass. This attribute is able to run normal tests also.

In this post we saw how easily we can run unit tests for async code, without having to hack our calls.

Read More

How to start Windows Azure emulator when running unit tests

Unit test need to be written even if we are working with on-premise services or with services from cloud. When working with Windows Azure, there are times when we want to write some integration test for Windows Azure tables, blobs or queues.
For these cases we don’t want to hit the Windows Azure from the cloud. This would increase or monthly subscription costs. Usually for this this Windows Storage emulator is used in combination with development storage account.
When we are on a development machine, where we already have Windows Azure Emulator stared we will not have any kind of problems. But will happen on a machine where Windows Azure Emulator is not started. All the tests will fail.
We can write a code in the class initialize step that star the emulator. In the end, the emulator is only a process that can be started from the command line.
The code that we would need to use will look something like this:

public class CloudStorageEmulatorShepherd
    {       
        public void Start()
        {
            try
            {
                CloudStorageAccount storageAccount = CloudStorageAccount.DevelopmentStorageAccount;

                CloudBlobClient blobClient = storageAccount.CreateCloudBlobClient();
                CloudBlobContainer container = blobClient.GetContainerReference("test");
                container.CreateIfNotExist(
                            new BlobRequestOptions()
                                {
                                    RetryPolicy = RetryPolicies.NoRetry(),
                                    Timeout = new TimeSpan(0, 0, 0, 1)
                                });
            }
            catch (TimeoutException)
            {
                ProcessStartInfo processStartInfo = new ProcessStartInfo()
                {
                    FileName = Path.Combine(
                                        @"C:\Program Files\Microsoft SDKs\Windows Azure\Emulator",
                                        "csrun.exe"),
                    Arguments = @"/devstore",
                };

                using (Process process = Process.Start(processStartInfo))
                {
                    process.WaitForExit();
                }
            }
        }
    }

The path to the emulator can be different, based on Windows Azure version. This path can be extracted in the configuration file.  We are testing if the emulator is started by trying to creating a container.  It is very important to set the  NoRetry policty.
And in our unit test we would need something like this:

[ClassInitialize()]
public static void ClassInit(TestContext context)
{
    CloudStorageEmulatorShepherd shepherd= new CloudStorageEmulatorShepherd();
    shepherd.Start();
}

In this way, we will be able to run integration test with Windows Azure without any kind of problem.

Read More

Day 1 of Software Architecture 2012 & Unit Test Patterns

This week I attended to Software Architecture 2012 conference from London. This was the first day of the conference and I decided to participate to a full day workshop about design patterns that was held by Andrew Clymer and Richard Blewett.
After this day I made a clearer image in my mind about some design pattern and how we can use it. There are a lot of new things that I discovered today. A part of them will be covered in future blog posts.
I looked over my today notes and I’m trying to extract some information for this blog post, but there are a lot of great things, that I feel the need to dedicate an entire post about it.
I will make only a small introduction into Unit Test Patterns. Any programmer should write unit tests. As we study design patterns in general we should learn also about unit test patterns.
In the last period of time the software industry become mature from many perspectives. The testing area, especially unit testing has reached his maturity. With this maturity, some pattern for unit testing appeared and guys don’t thing if you are a developer you should not know about this. This things are not for testers, are for you, for developers. Developers write unit test and not testers. Also understanding unit testing and pattern that are related to unit testing will improve our production code.
The simplest pattern is “Simple-Test”. This is the most basic unit test pattern that validate that for a valid input the expected outcome is obtained. In the case if our code contains an error trap, than we need to create a test for this case.
Suppose that we have a class Calculate that calculate the sum of two numbers. We will need to write a test that validate that the sum for two numbers is calculated correctly. This test will not guarantee that our code is valid and will work for any kind of input data. It only validate the most simple and basic happy flow.

public class Calculator
{
        public int Sum(int a, int b)
        {
            if (a == 0)
            {
                return b;
            }
            if (b == 0)
            {
                return a;
            }

            return a + b;
        }
}

[TestClass]
public class CalculatorTests
{
    Calculator calculator=new Calculator();

    [TestMethod]
    public void SumOfTwoSimpleNumbersReturnsTheSumOfNumbers()
    {
        Assert.AreEqual(10,calculator.Sum(2,8));
    }
}

Another well know pattern is “Code Path”. In the first pattern we didn’t look over the code. We tested it with the happy flow. The Code Path Pattern is used to test all the paths from our code. In this way, we will be more confident about out code quality. When we are writing this kind of unit tests we don’t look over the requirements, because we could miss some paths from our code. Code Path Pattern requires looking through the code in a “white box” method and covering all the possible paths. When we are using this pattern over legacy code you may be shocked about the number of lines of codes that are not used anymore.

[TestClass]
public class CalculatorTests
{
    Calculator calculator=new Calculator();

    [TestMethod]
    public void SumOfTwoSimpleNumbersReturnsTheSumOfNumbers()
    {
        Assert.AreEqual(10,calculator.Sum(2,8));
    }

    [TestMethod]
    public void SumWhenFirstNumberIsZeroReturnsSecondNumber()
    {
        Assert.AreEqual(5,calculator.Sum(0,5));
    }

    [TestMethod]
    public void SumWhenSecondNumberIsZeroReturnsFirstNumber()
    {
        Assert.AreEqual(3, calculator.Sum(3, 0));
    }

}

The last pattern that I will describe now is “Parameter Range”. When we are writing unit test, we should test our code with more than one input data. Even if we tested all the paths of our code this will not guarantee that our code is perfect.
For example in the previous example we should test what is happening if we calculate the sum of two big numbers that will generate a value that exceed the maximum value.

    [TestMethod]
    public void SumOfTwoSmallNumbersReturnsTheSumOfNumbers()
    {
        Assert.AreEqual(7, calculator.Sum(3, 4));
    }

    [TestMethod]
    public void SumOfTwoBigNumbersReturnsTheSumOfNumbers()
    {
        Assert.AreEqual(180, calculator.Sum(100, 80));
    }

    [TestMethod]
    public void SumOfTwoPrimeNumbersReturnsTheSumOfNumbers()
    {
        Assert.AreEqual(24, calculator.Sum(11, 13));
    }

I would like to congratulate the speakers of this workshop. I think that you made us thinking and see the design patterns from other perspectives.

Day 1

Day 2

Day 3

Day 4 

Read More

New Unit Tests features of Visual Studio 2012

Visual Studio 2012 was already lunched some time ago. A lot of new feature were introduce with this new version. Some changes from Visual Studio 2012 are big and from some point of view, the difference between the old version of Visual Studio and the new one are like the difference between Windows 8 and Windows 7.

 I think that a lot of developers already played a little with this new version of Visual Studio. The first thing that you notify after installing it is the time that is necessary to load the new Visual Studio – that is very low. The second thing is the new UI, that is Metro like.

One zone where Visual Studio 2012 made a big step forward was Unit Testing. A lot of new feature were introduce in this area that not only increase the productivity of the developer, but also increase the quality of the code. In the next part of the post we will discover what are the main new features that were introduce from the unit testing perspective.

Run tests after each build

In the old version of Visual Studio, we didn’t have a build in mechanism to run unit tests after each build. Because of this we had to click on “Run All Tests” each time when we build the solution. This could be annoying after a while. Visual Studio 2012 already has this feature build in and with only one click we can activate or deactivate this feature.

All the tests run in background, without bothering us.

Debug/Run tests from direct from code

How many time you had to go to the Test Explorer window to be able to run your current test. From now one, Visual Studio 2012 have a shourcut in the menu that will run the test that are selected in the code.

Group and run unit test based on the category

From now one we can add one or more categories to our unit test. This attribute can be added not only to each test in part but also to the unit test class. Using this feature we can run unit tests only from a specific category. This is a great feature when not only on the developers’ machine, but also on the build machines.

To be able to run the unit tests that have a specific category from command line we need to specify the TestCaseFilter option:

Vstest.console.exe myFooProject.dll 
   /TestCaseFilter:”TestCategory="Atomic"

Assert.ThrowsException

Until now, if we had a unit test that would check if a method throws an expected exception; we would have to decorate our method with an attribute. But this is not the best solution, because there were cases when we could not determine precisely the source of the exception.

In this moment this feature is available only for Windows Store Application. We hope that this new feature will be also available for other type of projects also.

Smart unit test discovery

The algorithm that is used to discover new unit test was improved. In this moment the new unit tests are discover extremely fast. We don’t need to rebuild the solution and wait until the new unit tests are discovered by Visual Studio.

Integration with JavaScript

Using a plugin like Chutzpah Test Adapter, we are able to run unit test written in JavaScript and run them in Test Explorer. Not only this, but we can run test written in C# and JavaScript in the same time. In this way we can run the entire test as one thing. The only thing that is necessary to be done is to install Chutzpah Test Adapter and use a unit test package for JavaScript like qunit.

Unit testing is a lot easier with this new version of Visual Studio. These are only a part of the new features that Visual Studio 2012 brought to us. You can try it and discover by yourself these new great features.

Read More

How to write unit tests in JavaScript for a Windows Store Application

Did you ever tried to write a Windows Store Application for Windows 8 in JavaScript? If yes than I hope that you started working on unit tests also. If no, than in this post we discover how we can write unit test for JavaScript and how we can integrate them in Test Explorer.
First of all why we need to write unit test for JavaScript? Because is like any other programming language that we used until now. When we write code in any language we need to test it. The framework and steps that are describe in this post can be used to write unit tests for JavaScript for a ASP.NET application of for any other project written in JavaScript.
To be able to write test in JavaScript we need to define our test methods that contains a collection of checks. We can write this from scratch or we can use a framework. For this purpose I recommend qunit.  This is a great framework that can be used to write unit tests. We have different version of qunit for Windows Store Application and ASP.NET. After you download this package all that you need to do is to create a project and add this project to it.
After this, all that we need to do is to start writing the unit tests. Basically we need t define a list of function and using methods like equal we can check our unit test assertion. We have a lot of assertion:

• equal – check if two values are equal
• notEqual – check if two values are different
• deepEqual – check if two values are equivalent
• notDeepEqual – check if two values are not equivalent
• strictEqual – check if two values are strict equal (“===”)
• notStricEqual – check if two values are not stric equal (“!==”)
• throws – check if our code throws an exception

The “test” method gives us the ability to define our test function and set the name of our test method. We can define a lot of things but these are the based things that we need. In the following example we define two test methods:

(function () {
    "use strict";
 
    test("my first test", function () {
        var v1 = 5;
        var v2 = 10;
        var sum = v1 + v2;
        equal(15, sum, "Our custom message.");
    });
 
    test("my seccond test", function () {
        var v1 = 5;
        var v2 = 10;
        var sum = v1 - v2;
        equal(15, sum, "Our custom message.");
    });  
})();

In a project for Windows Store when we will run it, qunit will generate a nice UI that will contain the status of each unit test.

As you can see we have a very nice interface that was created where we can read the status of our tests.
Another thing that I like to qunit is the way of output is generated. The output of running the tests is an XML. Over this file a styling is applied for a Windows Store Application. This XML can be used very easily with MSBUILD. There are a lot of scripts that already do this thing.
As you know Visual Studio 2012 contains an improved Test Explorer. Using a plug-in named Chutzpah Test Adapter for the Visual Studio 2012 we can integrate this test in our Test Explorer. In this way we will able to run our C# and JavaScript tests in the same time.

 Using qunit in combination with this plug-in we can create and run unit tests in JavaScript for Windows Store Application without any problem.
Good luck with unit tests.

Read More

Unit test classes - using a base class

Mai mult ca sigur cu toții am scris teste. 1,2, 3 .. n clase de teste. Într-un anumit moment ajungem sa dorim sa refactorizam codul, iar o parte din logica (setup-ul testelor) sa îl ducem în clasa de baza.

public class Test1: BaseTest
{
    [TestMethod]
    public void Method1Test()
    {
        Console.WriteLine(&quot;Method1Test&quot;);
    }

    [TestInitialize]
    public void TestInit()
    {
        Console.WriteLine(&quot;TestInitialize&quot;);
    }
   
    [TestCleanup]
    public void TestCleanup()
    {
        Console.WriteLine(&quot;TestCleanup&quot;);
    }
   
    [ClassInitialize]
    public static void ClassInit(TestContext testContext)
    {
        Console.WriteLine(&quot;ClassInit&quot;);
    }      
}

Sa ne uitam acuma la clasa de baza:

public class BaseTest{   
    [TestInitialize]
    public void BaseTestInit()
    {
        Console.WriteLine(&quot;BaseTestInitialize&quot;);
    }
   
    [TestCleanup]
    public void BaseTestCleanup()
    {
        Console.WriteLine(&quot;BaseTestCleanup&quot;);
    }
   
    [ClassInitialize]
    public static void BaseClassInit(TestContext testContext)
    {
        Console.WriteLine(&quot;BaseClassInit&quot;);
    }      
}

Totul pare in regula, in mod normal la rularea testului va asteptati sa ruleze in felul urmator:

• BaseClassInit
• ClassInit
• BaseTestInit
• TestInit
• Method1Test
• TestCleanup

Dar o sa avem parte de o surpriza:

• ClassInit
• BaseTestInit
• TestInit
• Method1Test
• TestCleanup

BaseClassInit nu a fost apelat. Chiar dacă ne-am aștepta ca metoda din clasa de baza sa fie apelata, iar în alte framework-uri este suportat (NUnit) acest comportament, M$ nu ne prea ajuta în acest caz.
La aceasta problema eu am văzut 3 posibile soluții, de la caz la caz ele pot sa fie aplicate sau nu:

1. clasa de teste care mosteneste clasa de baza sa apeleze explicit BaseClassInit. Dar acest lucru ne obliga avem o metoda decorata cu ClassInitialize in fiecare clasa derivata (poate nu ne dorim acest lucru);
2. in unele situații, putem sa mutam logica din BaseClassInit în constructorul static:

static BaseTest()
{
    Console.WriteLine(&quot;BaseClassInit&quot;);
}

      3.  prin reflection putem sa facem un hook si sa ne implementam noi acest mecanism. Dar este destul de complex si nu cred ca merita;
Din fericire avem cateva solutii la indemana, dar uneori dupa o refactorizare ne putem trezi ca ne cad testele si sa nu gasim cauza exacta.

Read More