Skip to main content

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:
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:

Comments

Popular posts from this blog

Windows Docker Containers can make WIN32 API calls, use COM and ASP.NET WebForms

After the last post , I received two interesting questions related to Docker and Windows. People were interested if we do Win32 API calls from a Docker container and if there is support for COM. WIN32 Support To test calls to WIN32 API, let’s try to populate SYSTEM_INFO class. [StructLayout(LayoutKind.Sequential)] public struct SYSTEM_INFO { public uint dwOemId; public uint dwPageSize; public uint lpMinimumApplicationAddress; public uint lpMaximumApplicationAddress; public uint dwActiveProcessorMask; public uint dwNumberOfProcessors; public uint dwProcessorType; public uint dwAllocationGranularity; public uint dwProcessorLevel; public uint dwProcessorRevision; } ... [DllImport("kernel32")] static extern void GetSystemInfo(ref SYSTEM_INFO pSI); ... SYSTEM_INFO pSI = new SYSTEM_INFO(

Azure AD and AWS Cognito side-by-side

In the last few weeks, I was involved in multiple opportunities on Microsoft Azure and Amazon, where we had to analyse AWS Cognito, Azure AD and other solutions that are available on the market. I decided to consolidate in one post all features and differences that I identified for both of them that we should need to take into account. Take into account that Azure AD is an identity and access management services well integrated with Microsoft stack. In comparison, AWS Cognito is just a user sign-up, sign-in and access control and nothing more. The focus is not on the main features, is more on small things that can make a difference when you want to decide where we want to store and manage our users.  This information might be useful in the future when we need to decide where we want to keep and manage our users.  Feature Azure AD (B2C, B2C) AWS Cognito Access token lifetime Default 1h – the value is configurable 1h – cannot be modified

What to do when you hit the throughput limits of Azure Storage (Blobs)

In this post we will talk about how we can detect when we hit a throughput limit of Azure Storage and what we can do in that moment. Context If we take a look on Scalability Targets of Azure Storage ( https://azure.microsoft.com/en-us/documentation/articles/storage-scalability-targets/ ) we will observe that the limits are prety high. But, based on our business logic we can end up at this limits. If you create a system that is hitted by a high number of device, you can hit easily the total number of requests rate that can be done on a Storage Account. This limits on Azure is 20.000 IOPS (entities or messages per second) where (and this is very important) the size of the request is 1KB. Normally, if you make a load tests where 20.000 clients will hit different blobs storages from the same Azure Storage Account, this limits can be reached. How we can detect this problem? From client, we can detect that this limits was reached based on the HTTP error code that is returned by HTTP