Minimal unit test setup Visual Studio 2017, Karma, Jasmine, Angular2, Typescript

Coming from the .net world setting up a first unit test for my angular side project was a very painful experience. Due to the sheer amount of frameworks and configuration I had to put a lot of time into it and spend a lot of time googling. The number of frameworks doesn't help and it's difficult to find exactly the same combination that you've chosen for your project. I've decided to use Karma because it was used in one of the first Visual Studio + Karma + Typescript tutorial I've found (later I've learnt from my close friend that it wasn't the best of choices).

I've decided to use the Visual Studio 2017 + ReSharper, first because I love these tools, second because I had my Azure WebJob and my WebService projects in the same solution as my angular2 based website.

It took a lot of time for me to go through it (after quite a bit of time I was able to run my tests from ReSharper but my goal was to make it run using either gulp tasks or NPM scripts tasks. After many retrials and tests I've narrowed down my Karma config (karma.conf.js) to the one below:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41

module.exports = function (config) { config.set({ frameworks: ['jasmine', 'karma-typescript'], files: [ 'tests/**/*.js', 'tests/**/*.ts' ], karmaTypescriptConfig: { compilerOptions: { module: 'commonjs', target: 'es2015' }, tsconfig: 'tsconfig.json' }, preprocessors: { '**/*.ts': ['karma-typescript'] }, reporters: ['progress', 'htmlDetailed'], plugins: [ 'karma-phantomjs-launcher', 'karma-jasmine', 'karma-typescript', 'karma-html-detailed-reporter' ], htmlDetailed: { splitResults: false }, port: 9876, colors: true, logLevel: config.LOG_INFO, autoWatch: true, browsers: ['PhantomJS'] }); }

Most of the errors I was receiving stemmed from the miss-configuration, and the fact that I was missing some dependencies. Karma is very configurable and most probably using something more simple like Tape would have set me off much faster.

Others steps I've taken to make it run/troubleshoot:
- installed Task Runner Explorer extension, which gives a nice gui for the tasks
- I've checked running the tests both in PhantomJS and headless Chrome
- when I was looking for errors I've switched logging level to Verbose, being able to see the logs being displayed in the Task's Runner output was something, which has greatly helped me pinpoint different issues
- using karma-typescript pre-processor for the ts files along with its config helped me with a lot of errors caused by unexpected token errors
- many of the errors were related to the incorrect module system or ecma script version
- first unit test (or spec file) which I've successfully launched was also my 'proof of concept' and was really simple:

1 2 3

describe('1st tests', () => { it('true is true', () => expect(true).toBe(true)); });

Set up page reload/type script compilation on save in Visual Studio 2015 with typescript

      The goal is to be able to transfer the changes done in TS code during debugging onto the running website. This is possible in Visual Studio using the Browser Link functionality. Whenever we debug and we've got Browser Link Dashboard open - we should be able to see our browser of choice during the debug session listed under specific projects.

This can actually allow us to have the same project being run in multiple browsers and refreshed in all at the same time.

Straight away we learn about the particular items which must be fulfilled to make it work:

1.       Static HTML files linking should be enabled by adding the following to the Web.config:
 

<system.webServer>

<handlers>

<add name="Browser Link for HTML" path="*.html" verb="*" type="System.Web.StaticFileHandler, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" resourceType="File" preCondition="integratedMode" />

</handlers>

2.       Debugging must be enabled in the Web.config file (this will typically be added to your web.config by default)

<system.web> <compilation debug="true" targetFramework="4.5.2"/>
 

3.       IIS server must run on .NET 4.0 or later.
 

4.       Compile on save has to be enabled in project options or particular setting in the csproj file has to be set (this can actually be changed mid-debugging):

Project properties:

Project file:

<TypeScriptCompileOnSaveEnabled>True</TypeScriptCompileOnSaveEnabled>

5.       Server side caching (files cached by IIS)

Add the following line to Web.config to instruct IIS not to cache files:

You need to set

<caching>
   <outputCache enableOutputCache="false" />
</caching>

or if its IIS 7+ (Which IIS Express will be)

<system.webServer>
    <caching enabled="false" />
</system.webServer>

6.       Client side caching (in-browser caching)

Chrome:
An option is to "Disable cache" in Dev Tools -> Networking
 

This will however force you to have Dev Tools open while debugging. There's a similar functionality for FireFox where caching can be only disabled for as long as long the developer tools are opened. To simplify working with such setup it's good to open Dev Tools in a separate window - even if you're not using it in this specific case you can keep it opened in the task bar.

7.       There are numerous examples of running Chrome in a non-caching mode, neither worked for me (chrome opened from command line with incognito mode, disabling application cache with an argument or outright setting the cache limit to a very small number. In my case it only worked for the first index file opened but the template html files used in components were not getting refreshed.

Environment used:
Visual Studio 2015 Update 3

Resharper 2016.2

Project created using Angular2WebTemplate

Someone's workaround:

http://stackoverflow.com/questions/41108995/using-angular-2-vs2015-and-iis-how-can-i-get-my-html-template-changes-to-refl

The "IsFileSystemCaseSensitive" parameter is not supported by the "FindConfigFiles" task error.

    I've recently started working on a small project with angular used on the front end. Part of it was adding the project from template (I've used a popular scaffolding Angular2WebTemplate). I've installed required nugets: Microsoft.TypeScript.Compiler and Microsoft.TypeScript.MSBuild.

After first build I've received the following error:
The "IsFileSystemCaseSensitive" parameter is not supported by the "FindConfigFiles" task error.

It took me a bit of digging to find this:
https://github.com/Microsoft/TypeScript/issues/15536

The issue seems to have been caused by two imports covering 2 different version of the same targets file. The solution was to remove one of the imports. Below a solution pasted from the above url:

Remove the local import (or Nuget import which ever one you choose). 

• local

 <Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets" Condition="Exists('$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\TypeScript\Microsoft.TypeScript.targets')" />

• Nuget - should be near the end of the proj file

 <Import Project="..\packages\Microsoft.TypeScript.MSBuild.2.3.1\build\Microsoft.TypeScript.MSBuild.targets" Condition="Exists('..\packages\Microsoft.TypeScript.MSBuild.2.3.1\build\Microsoft.TypeScript.MSBuild.targets')" />

In my case I've removed the first entry which was enough to make the project compile and run.

Object copying speed comparison, Part 2

      As planned - I'm adding another part of the overview of different methods used in the previous post. I'll try to dive into different nooks and crannies and see what I can learn from it. Before that I'd like to address questions raised.

1. It is unfair to compare converting done in parallel and the one done solely with AutoMapper. And unfair it is indeed. My goal however was to have an interesting learning experience. I wasn't planning to have a race.

2. Some of the cases don't make sense. And again it's correct. Most of them don't. Most of the time it's not the code that does objects conversion, which is our production code's bottleneck. Most of the time we'll find our performance issues elsewhere. Similarly as above - we're trying to have fun here and learn something new.

Going back to the samples:

1. ManualMap - simple creation of the view models objects and copying of the data. First thing, which can increase the performance is setting the capacity of the output list to a predetermined size. Bear in mind this will become visible only with the increase of the items count.
   
                 
   
   The cause for this is memory reallocation and GC.
   Here's a good explanation: http://stackoverflow.com/questions/2247773/is-it-worthwhile-to-initialize-the-collection-size-of-a-listt-if-its-size-rea
2. ManualMapFor - uses a for loop to iterate through the collection. In our case it was ~30%
   faster than the foreach version. Depending on the underlying collection the results may very. Iterating through arrays should be fastest due to the generated IL optimizations.
   Here's a good read on specifics:
   http://codebetter.com/patricksmacchia/2008/11/19/an-easy-and-efficient-way-to-improve-net-code-performances/
3. AutoMapperMap - this case uses an AutoMapper library, which allows us to workaround the boilerplate code of copying the objects. It requires initial configuration - and it is slower, than using a manual copy adapter class. What we gain is the lack of all the extra boilerplate. Based on the results it was 10 times slower, than using manual adapter with a foreach loop.
   
   It would have been slightly faster, if we used a for loop over an array.
4. AutoMapperCollectionMap - the mapping is always faster when we register a collection within the mapper. Performing a mapping of collection of objects to another collection of objects. Whenever we use Automapper that's the recommended way of performing the mapping.
5. LinqMap - the most basic comparison to do was to compare it against an ordinary foreach loop. The LinqMap does a simple Select to do the mapping and ToList at the end. I expected it to be slower. This is how the comparison looks like:
   
   
   
   Select statement based on the collection it is running on, internally chooses an iterator, hence depending whether it's list or array we might get a speedup. Additionally Linq statements such as Select and Where use iterators, which allow for optimizing consecutive chained Where and Select calls. The logic behind them adds additional performance hit.
   
   To be continued...

General optimizations:

1. Many .NET library methods perform optimizations based on type of collections we pass as a parameter. When we use the generic IEnumerable many will perform a check to see whether the collection implements ICollection, IList or whether it is an array. Knowing the more specific interface allows to use methods which make faster execution possible. Reads and writes themselves can differ in speed due to how out of bounds checks are performed in different cases. In the test below a foreach loop has performed manual copying over an array of dtos and a list of dtos. The array version is visibly faster.
   
   
   

Object copying speed comparison

       I've been wondering about speed differences in execution of property copying code, which is usually used/found in the adapter pattern implementation. The answers are obviously in stackoverflow and in various blogs. But I thought about pushing it a bit further and comparing speeds of different approaches to this issue.

Bear in mind different ways of doing the same thing have advantages and disadvantages and each way has different caveats. I've selected a couple of approaches, there are many which I've either missed or disregarded. Some of the listed methods have minimal differences between them - or would never be used in production code.

As a common use case for all I've selected copying data between a data transfer object (DTO) object and a View Model object.

1. ManualMap - an ordinary property by property copying of whatever is in the object. Most often this is how it's done manually. Uses a foreach loop to loop through the objects.
2. ManualForArrayMap - takes in an array of Dtos and uses a for loop. It could use a list as well.
3. LinqMap - same as the foreach one but uses Linq to loop through the items.
4. AutoMapperMap - uses automapper and foreach loop to loop through all the items
5. AutoMapperLinqMap - similarly as above but uses Linq
6. AutoMapperCollectionMap - maps the whole collection in one go instead of looping through the items and mapping one by one.
7. ILMap - uses Emitted code which is cached as a delegate. Generic.
8. ExpressionMap - uses expressions to bind properties of the objects. Generic.
9. ReflectionOrderedPropertiesCopy - uses reflection with the assumption that the properties are ordered. Generic.
10. ReflectionPropertySearchCopy - uses reflection and searches for each property within the object by name. Generic.
11. ParallelForEachManualMap - uses a partitioner and a parallel foreach loop to split the collection into separate ranges.
12. ParallelLinqMap - parallel linq with the use of AsParallel method. Checked a couple of times with different degrees of parallelism set.

The slowest out of these were the ones which use reflection (9 and 10), I haven't added them in the comparison cause numbers were off the chart. 7 and 8 use reflection as well but only when building the lookup - the time required for it is not taken into consideration, similarly as AutoMapper configuration.

To check the timings I've used DotNetBenchmark library, I've run it in release outside of Visual Studio to have fairly correct results. All the results below are actually a median taken out of multiple runs of the same method.

Below you can see the comparison of timings for different numbers of DTOs fed into the methods, all of these timings are in nanoseconds.

Comparison of timings.

Next I've created a chart based on the above.

There are some obvious takeaways above. I'll go into more details in the next post.

I'm pretty sure I have missed something or introduced some errors in the code - if you notice anything feel free to let me know. The code itself is sometimes under optimized and sometimes over optimized - but it was not the point of this specific post - it was more getting the general feeling of how fast can this boilerplate code run.

Links:

Github with sources for the comparison project: https://github.com/simonkatanski/speedtest/

BenchmarkDotNet: https://github.com/PerfDotNet/BenchmarkDotNet

TabItem Validation Sample

     Recently I've been asked several questions on the TabItem tutorial I've done some time ago. Because I haven't had any sources containg the code at hand I've finally found the time to refresh my memory and cobble together a sample.

Below sample is just a proof of concept. The code shouldn't be looked at as an example of good design and was prepared only to show the validation of tab items. In a production code ViewModels wouldn't be created in the view and command would be used instead of on click event for the button. Event aggregator, message bus or some other pattern could be used for exchange of information between the view models. Please treat this code as a very rough scaffolding. The sample follows the tutorial introduced some time ago, hence no refactoring or cleaning has been done.

Previous tutorials:

   TabItem Validation, Part 1
   TabItem Validation, Part 2

Code:

   https://github.com/simonkatanski/ValidationSample

Nuget cheat sheet

         I use nuget from the nuget console rarely enough to always have to google for the commands I need. Hence, here's a couple of commands I use most often:

Install-Package NUnit
Uninstall-Package NUnit

Lists all package's versions available from the current source based on the filter word:

Get-Package -ListAvailable -AllVersions -filter NUnit -source https://nuget.org/api/v2/

If we want to install some specific version of a package, we can use:

Install-Package NUnit -Version 1.0.0

If we want to install specific package into specific project:

Get-Project NameOfTheProject | Install-Package NUnit

Or, if we want to install specific package for all projects:

Get-Project -All