dot net notts js unit testing at microlise
Post on 13-Jul-2015
Embed Size (px)
Adoption in the Enterprise
firstname.lastname@example.org - @JonGregory77
A few quick questions
Jon Gregory Technical Architect at Microlise, have been working with .Net since 2.0
Microlise supply vehicle tracking, telematics and proof of delivery solutions.
Our approach to adopting JS Unit Testing
Thank you for coming
Technical Architect at Microlise, What does a Technical Architect do at Microlise?
Well most of it is sounding confident and blagging but sometimes I get to look at tools and techniques.
As you heard Microlise is telematics company and primarily a Microsoft .Net Software house.
We had no background in this and this talk is aimed at showing how we got started, where we are now and what we are going to do next.
If you have any feedback or are doing something different with JS Unit Testing would be great to hear about it
Two Large Web Forms / MVC Hybrid Applications
Increasing use of front end logic
UX team using bootstrap based UI framework
We have two large web application which started life as years ago using Web Forms and now have MVC added in.
We are migrating to MVC and not got much left to do
Ball of Wool Design Pattern!
Because it is not the primary language used and doesn't have the same tool set support in VS
Found it has not always had the same level of attention as with the C#.
Difficult to read unstructured files
Multiple JQuery versions
JQuery selectors binding to the view
Ball of wool design pattern!
Some of the naughty things that have happened
Multiple versions of JQuery reluctant to upgrade for risk of breaking.
It Has Become costly and Time Consuming to support
Invested heavily in C# Unit Testing
Benefits in good design & confidence in code
We have been using Unit Testing for a number of years on the C# side and the concepts were well understood.
We knew the benefits were
Confidence in Code
Early Detection of Bugs
Improved Quality of life :)
Perception it wouldn't add value
Wasn't clear what could be tested
We hadn't looked at what was possible
Visual Studio didn't provide the tools
Wasn't all plain sailing
Some people were all for it, others were less keen
Some of the initial feedback was
Difficult to do
Poor tooling available
Lot of Effort for little reward
There wasn't enough logic in JS to test
So we had some work to do to meet these challenges and convince people it was worth doing.
C# => JS
We needed a solution that would be friction free and easy for everyone to adopt.
We wanted to transition Unit Testing and mocking skills gained in C# to JS
Looking for something that was as close as possible to NUnit and MOQ as practically possible.
Aimed to provide a framework and resources so developers could start quickly and just concentrate on writing tests.
If its not easy and fun to write tests then we wouldn't get quality tests produced
We had big constraint in some customers use IE8 , we supply to the transport and public sectors and they are slow to upgrade.
Anything we chose had to work well with IE8
There are many many tools available now, too many to be able to practically evaluate.
We looked at the three most mentioned in the community.
QUnit - TDD
Jasmine - BDD
Mocha All the above!
Many tools available
Community recommended top three
QUnit, Jasmine and Mocha
QUnit and Mocha need a mocking framework
Jasmine provides its own mocking framework but Mocha and QUnit don't so also looked at SinonJS
Chose mocha because most flexible and can run in node for command line work
Can use BDD and TDD style for test and QUnit Tests.
TDD closer to the way we are currently working
Mocha ships with Chai.js as the expectation framework.
This is the provider that does the assertion at the end of the test, chai.js does not support IE8
Fortunately Mocha allows you to substitute this an we can use Expect.js which supports IE8.
Can swap for each test suite so not restricting ourselves.
Needed to be able to run the tests!
ReSharper plugin available for Mocha but requires NodeJS
Chutzpah easier and free Visual Studio plugin
Chose to look at running in Node as a Phase 2
Plugin available to run Mocha tests in Resharper
But there is a great visual studio plugin called Chutzpah which is free
Will show Chutzpah later in code demo
Chose to use Mocha MVC Controller so can be able to run from a web page
This is hidden behind a permission attribute - retain the option to run on customer site for investigation
Can also run from Static HTML for non MVC application
We new the tests could be run from the command line using node and then integrate into build process, we chose to leave this to a phase 2 once the processes had been adopted and we had a suite of tests.
This was just down to time constraints
File structure convention
Mocha Controller added to MVC Applications
Training and sample applications
Visual Studio / Resharper Templates
So we had chosen;
Mocha as the test frameworkSinonJS for the Mocking / Test Double FrameworkAnd Expect.js as our IE8 friendly expectation framework
How were we going to approach the implementation and rollout.
Visual Studio Templates for test files and projects with all the infrastructure required.
Created a Sample Application with basic tests in for each technique Mocking, Stubs etc etc
Help Hands on Training Session with simple exercises so everyone could have a go.
File Structure - MVC
ASP.Net nased on convention over configuration
We wanted a convention so we didn't end up with tests smeared through the application.
If everything is under a folder called test we can pick this up with a test runner as part of the build process mocha defaults to looking for a Test folder (mention typo)
The tests follow the same convention allowing the file under test and the test to be related.
File Structure - Logic
Again allows the file under test and the test file to be related.
The mother in law gets upset when I use her picture in presentations
Looking at ways of adding into out continuous integration & inspection process
NCrunch Style continuous runner.
Continuing to promote and train to increase uptake
We are looking at ways of adding into out continuous integration and Continuous Inspections to monitor quality and coverage
Looking at Karma, Testacular, PhantomJS
Still some adoption challenges to get over, large part of this work has been coaching and promoting
Separate out selectors to prevent having to mock