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(...

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine: threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See http://go.microsoft.com/fwlink/?LinkId=260882 for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration: TeamCity .NET 4.51 EF 6.0.2 VS2013 It see...

Navigating Cloud Strategy after Azure Central US Region Outage

 Looking back, July 19, 2024, was challenging for customers using Microsoft Azure or Windows machines. Two major outages affected customers using CrowdStrike Falcon or Microsoft Azure computation resources in the Central US. These two outages affected many people and put many businesses on pause for a few hours or even days. The overlap of these two issues was a nightmare for travellers. In addition to blue screens in the airport terminals, they could not get additional information from the airport website, airline personnel, or the support line because they were affected by the outage in the Central US region or the CrowdStrike outage.   But what happened in reality? A faulty CrowdStrike update affected Windows computers globally, from airports and healthcare to small businesses, affecting over 8.5m computers. Even if the Falson Sensor software defect was identified and a fix deployed shortly after, the recovery took longer. In parallel with CrowdStrike, Microsoft provi...