Practical Guide to Unit Testing
Upcoming SlideShare
Loading in...5
×
 

Practical Guide to Unit Testing

on

  • 3,494 views

Slides from the talk I gave at meet.js summit in Poznań, on January 14th 2012: http://summit.meetjs.pl/

Slides from the talk I gave at meet.js summit in Poznań, on January 14th 2012: http://summit.meetjs.pl/

Statistics

Views

Total Views
3,494
Views on SlideShare
3,335
Embed Views
159

Actions

Likes
3
Downloads
36
Comments
0

6 Embeds 159

http://szafranek.net 128
http://speakerrate.com 14
http://szafranek 13
https://twitter.com 2
http://a0.twimg.com 1
http://www.szafranek.net 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Practical Guide to Unit Testing Practical Guide to Unit Testing Document Transcript

  • Practical guide to unit testingKrzysztof Szafranek meet.js summit 2012 1
  • [ˈkʂɨʂtɔf ʂafranˈɛk] Roche front-end unit leader Nokia front-end architect wooga game developer 2Everything front-end.Currently HTML5 game developer @ wooga.
  • in pr ac tic unit test e™ a function created to test other function 3This is what it comes down to in JavaScript.
  • unit testing? 4Unit testing is very much like regular exercise:everybody knows it’s good, but few people do it.
  • I don’t know what are unit tests My code doesn’t need tests 3% 5% I don’t write tests, 47% but I would like to I write tests 45% 5The results of the poll I ran on my blog.I got 60 responses.
  • I don’t know what are unit tests My code doesn’t need tests 3% 5% I don’t write tests, 47% but I would like to I write tests 45% 5The results of the poll I ran on my blog.I got 60 responses.
  • tests increase confidence 6It’s easier to change code knowing that tests will show places affected by thechange.
  • tests encourage good design 7Tests force your methods to be short, simple and with very few dependencies.You end up in the code that’s not only less buggy, but also more readable.
  • collective ownership 8No, it’s not communism. It means that the code is guarded from harm by tests.Team members can confidently modify the code they didn’t write, as long as theyensure that test still pass.
  • one click to test them all 9With test runner all your tests can be run automatically at the same time in asmany browsers you want.
  • the “We don’t have time for that!” argument 10The most common excuse for not writing tests.
  • cumulative functionality si gn d e o od g no design design payoff line time 11The graph comes from Martin Fowler’s article: http://martinfowler.com/bliki/DesignStaminaHypothesis.htmlIt applies very much to unit testing.
  • cumulative functionality si gn d e o od g no design design payoff line time 11The graph comes from Martin Fowler’s article: http://martinfowler.com/bliki/DesignStaminaHypothesis.htmlIt applies very much to unit testing.
  • cumulative functionality si gn d e o od g no design design payoff line time 11The graph comes from Martin Fowler’s article: http://martinfowler.com/bliki/DesignStaminaHypothesis.htmlIt applies very much to unit testing.
  • “its much lower than most people think: usually weeks not months.” Martin Fowler 12From my own experience, if you work on the project for longer than one man-month, the tests are starting to pay off for themselves in better quality and lesstime spent on finding and fixing bugs.
  • the how 13
  • 1. test TD D 2. minimum code that works 3. refactor 4. repeat 14This behavior is Test Driven Development. Some people preferwriting implementation before tests. That can work too.
  • tools 15
  • buster.js test framework + test runner 16New, but already powerful framework by Christian Johansen:- extensible API with optional BDD syntax- easy mocking, also for server connections- easy to automate- node and browser tests
  • no de buster.js .js ! test framework + test runner 16New, but already powerful framework by Christian Johansen:- extensible API with optional BDD syntax- easy mocking, also for server connections- easy to automate- node and browser tests
  • config sources client server browsers 17The diagram is based on: http://code.google.com/p/js-test-driver/Buster implements most of the features of js-test-driver, andmore.
  • function async() { window.globalVar = false; setTimeout(function() { window.globalVar = true; }, 100); } buster.testCase("asynchronous tests", { "test async changes global variable": function() { var clock = this.useFakeTimers(); async(); clock.tick(200); buster.assert.equals(window.globalVar, true); clock.restore(); } }); 18One of my favourite buster features: making asynchronouscode with setTimeout running instantly. It keeps your tests fast.
  • UnitTesting TestCase Test.More TestIt screw-unit JSUnit QUnit jsUnitTest Jasmine Test.Simple Crosscheck Nodeunit YUITest DOH JSTest JSpec RhinoUnit J3Unit Sinon.js FireUnit js-test-driver JSNUnit JSSpec Vows SOAtest Tyrtle jsUnity JSTest.NET JasUnit 19There are many JavaScript unit testing frameworks and the above list (fromhttp://en.wikipedia.org/wiki/List_of_unit_testing_frameworks#JavaScript) isalready incomplete.
  • tools are secondary 20If you find a different framework that fits your needs, that’s fine. Actually writingtests is more important than a choice of a particular framework.
  • demo time! 21Demonstration of buster.js with a simple test run in two desktop browsers andiOS simulator.
  • 1. test2. minimum code that works3. refactor4. repeat 22
  • Practical guide to unit testing 23Thing’s I learned about JS unit testing myself.
  • e t ic a c p r in test what matters 24Don’t test getters and setters, but methods that actually do something
  • e t ic a c p r test in your own system 25Don’t test browsers, network connections and other external systems. If your unittests are sending requests over network, you’re doing something wrong.
  • e t ic a c p r in keep your tests fast 26- What is “fast”...?- 1 second is fast.
  • e t ic a c p r in write tests as you go 27I don’t belive in large retrospective refactorings.If you have a lot of untested code:- Write test BEFORE when you have to fix a bug. It will ensure the bug will notre-appear in the future.- Write tests for all new code.- Don’t refactor without writing tests first. Otherwise it’s running around withscissors, not refactoring.
  • e t ic a c p r in automate 28Early error detection for free.Use continuous integration software (Jenkins, Hudson, Cruise Control...).
  • e t ic a c p r in expect tests 29Tests should be part of your definition of done. A feature without tests can’t beconsidered complete.
  • I challenge you! 30Start writing tests the next time you write code after watching this presentation!
  • krzysztof@szafranek.net (name) Thank you! 31
  • krzysztof@szafranek.net (contact email) Thank you! 32
  • krzysztof@szafranek.net (twitter) Thank you! 33
  • krzysztof@szafranek.net (website) Thank you! 34
  • photo credits:pragdave edtechie99varun suresh cyberpenguinrwoan 35