Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (15)
Similaire à Js unit testingpresentation
Similaire à Js unit testingpresentation (20)
Js unit testingpresentation
- 1. JavaScript Unit Testing Adoption in the Enterprise jon.gregory@microlise.com - @JonGregory77
- 2. Introduction • 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
- 3. Drivers • Two Large Web Forms / MVC Hybrid Applications • Organically grown JavaScript • Unstructured large JavaScript files • Increasing use of front end logic • UX team using bootstrap based UI framework
- 5. State of JavaScript • In-line JavaScript • Difficult to read unstructured files • Multiple JQuery versions • JQuery selectors binding to the view • Ball of wool design pattern!
- 6. Unit Testing
- 7. Unit Testing • Invested heavily in C# Unit Testing • Benefits in good design & confidence in code • We wanted the same for JavaScript!
- 8. Challenges • 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
- 9. Friction Free C# => JS
- 10. Real World
- 11. Evaluation
- 12. Evaluation • Many tools available • Community recommended top three • QUnit, Jasmine and Mocha • QUnit and Mocha need a mocking framework
- 13. Test Runner • 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
- 14. Approach • File structure convention • Mocha Controller added to MVC Applications • Static HTML • Training and sample applications • Visual Studio / Resharper Templates
- 15. File Structure - MVC /Tests --/app ----/ControllerName ------/ViewName --------TestFileOne.Tests.js
- 16. File Structure - Logic /Scripts --/app ----/Maths ------Calculator.js /Tests --/app ----/Maths ------Calculator.Test.js
- 17. Code Demo
- 18. Success
- 19. Future
- 20. Future ● Looking at ways of adding into out continuous integration & inspection process ●Work to improve JavaScript coding techniques and writing structured JavaScript ●NCrunch Style continuous runner. ● Continuing to promote and train to increase uptake
- 21. Useful Links ● https://www.syncfusion.com/resources/techpor tal/ebooks/javascript ● http://www.sonarqube.org/ ● PluralSight – Testing ClientSide JavaScript ● Gil Fink – MSDN – Jasmine Talks
- 22. Questions ?
Notes de l'éditeur
- A few quick questions Whos using Javascript? Whos writing Tests for JavaScript? Who enjoys working with JavaScript? I enjoy working with JavaScript!
- 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. This talk is about how we approached adopting JavaScript Unit Testing. 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
- 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 Majority developers C# is first language and JavaScript is a means to an end for the client work. Working in a SCRUM style tend to get small task which have been adding into the JavaScript files a little at a time. Without controls this has led to large unstructured JavaScript files. Over the last few years we have adopted Knockout and Twitter Bootstrap derived UI framework and SignalR, which has led to increase use of JavaScript.
- Ball of Wool Design Pattern! Found it is very easy to quickly get in a bit of state with JavaScript. 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#.
- Some of the naughty things that have happened Small pieces of js added into views – then added to and added to over time so we end up with inline javascript C# Web forms developers – not experienced being closer to HTML and JavaScript JQuery selectors binding javascript to views Multiple versions of JQuery – reluctant to upgrade for risk of breaking. It Has Become costly and Time Consuming to support
- So we thought would Unit Testing JavaScript Help?
- 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 Improved Design Live Documentation Confidence in Code Early Detection of Bugs Improved Quality of life :)
- 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.
- 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 We had to be able to mock JQuery selectors to be able to support legacy JavaScript SinonJS allowed us to do this.
- 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!
- 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.
- 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
- So we had chosen; Mocha as the test framework SinonJS for the Mocking / Test Double Framework And 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.
- 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) Our MVC content files follow an internal convention which allows the javascript file and the MVC view to be related by name. The tests follow the same convention allowing the file under test and the test to be related.
- This second convention is for JavaScript files not related to MVC views Again allows the file under test and the test file to be related. No easy peasy resharper navigation available in javascript!
- This is my son Oliver being a proud dad wanted to find a way of getting him into the presentation Can we measure success? Well what did we want to achieve – easy uptake for C# developers and be able to test green and brown field JS. Adoption is increasing every sprint Several Developers have just picked it up and run with it without training JavaScript work is irregular so regularly promoting Halfway through the process!
- The mother in law gets upset when I use her picture in presentations
- We are looking at ways of adding into out continuous integration and Continuous Inspections to monitor quality and coverage We use NCrunch for C# want to create a continuous runner for JavaScript which is possible. Looking at Karma, Testacular, PhantomJS Still some adoption challenges to get over, large part of this work has been coaching and promoting Work to improve JavaScript coding techniques and writing better structured JavaScript, using Immediately Invoked Functions as seen in the code demo Separate out selectors to prevent having to mock
- I will tweet out bitly these links out tomorrow
- Any Easy Questions?