Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Test Framework Shootout: Jasmine

Test Framework Shootout: Jasmine

A run-down of the features and benefits of using a BDD framework for unit tests by running Jasmine.

Given at http://www.meetup.com/Charlotte-Front-End-Developers/events/166811032/

Bermon Painter

May 30, 2014
Tweet

More Decks by Bermon Painter

Other Decks in Programming

Transcript

  1. Types of Tests TESTS. LOTS OF TESTS. • SMOKE TESTS

    • INTEGRATION TESTS • USER ACCEPTANCE TESTS • REGRESSION TESTS • UNIT TESTS
  2. Types of Tests TESTS. LOTS OF TESTS. • SMOKE TESTS

    • INTEGRATION TESTS • USER ACCEPTANCE TESTS • REGRESSION TESTS • UNIT TESTS
  3. Unit Tests TESTS. LOTS OF TESTS. ENSURE YOU BUILD THE

    THING RIGHT • code functions as designed
  4. Unit Tests TESTS. LOTS OF TESTS. ENSURE YOU BUILD THE

    THING RIGHT • code functions as designed • run when code it compiled
  5. Unit Tests TESTS. LOTS OF TESTS. ENSURE YOU BUILD THE

    THING RIGHT • code functions as designed • run when code it compiled • run as a suite of tests
  6. Unit Tests TESTS. LOTS OF TESTS. ENSURE YOU BUILD THE

    THING RIGHT • code functions as designed • run when code it compiled • run as a suite of tests • better documentation
  7. Unit Tests TESTS. LOTS OF TESTS. ENSURE YOU BUILD THE

    THING RIGHT • code functions as designed • run when code it compiled • run as a suite of tests • better documentation • uncover bugs pre-QA
  8. TDD TDD vs BDD 1. Write tests 2. Tests fail

    3. Write code 4. Tests pass
  9. TDD TDD vs BDD 1. Write tests 2. Tests fail

    3. Write code 4. Tests pass 5. Refactor
  10. TDD TDD vs BDD 1. Write tests 2. Tests fail

    3. Write code 4. Tests pass 5. Refactor 6. Repeat
  11. BDD TDD vs BDD 1. Establish goals/vision 2. Involves team

    to describe the behavior of an app.
  12. BDD TDD vs BDD 1. Establish goals/vision 2. Involves team

    to describe the behavior of an app 3. Create code based on the behavior descriptions
  13. BDD TDD vs BDD 1. Establish goals/vision 2. Involves team

    to describe the behavior of an app 3. Create code based on the behavior descriptions 4. Automate the testing of your code (feedback/ regression testing)
  14. 1. Describe Behaviors (STAKEHOLDER + TEAM) ! 2. Write Scenarios/Specs

    (DEVELOPERS) ! 3. Run Tests (TESTS FAIL) ! 4. Write Code for Tests to Pass ! 5. Run Tests (TESTS PASS) FAIL PASS REFACTOR
  15. The hardest single part of building a software system is

    deciding precisely what to build. ! - Fred Brooks
  16. Matchers JASMINE ANATOMY describe (“Hello World”, function(){ it(“Says hello to

    everybody”, function(){ expect(helloWorld().toEqual(“Hello world!”)); }); });
  17. Matchers JASMINE ANATOMY • expect() • toEqual() • toBeTruthy() •

    toBeFalsy() • toContain() • toBeDefined() • toBeUndefined() • toBeLessThan() • toBeGreaterThan() • toMatch()
  18. beforeEach() JASMINE ANATOMY var runnerWideFoo = []; beforeEach(function () {

    runnerWideFoo.push('runner'); }); describe('some suite', function () { beforeEach(function () { runnerWideFoo.push('suite'); }); it('should equal bar', function () { expect(runnerWideFoo).toEqual(['runner', 'suite']); }); });
  19. afterEach() JASMINE ANATOMY describe('some suite', function () { var suiteWideFoo

    = 1; afterEach(function () { suiteWideFoo = 0; }); it('should equal 1', function () { expect(suiteWideFoo).toEqual(1); }); it('should equal 0 after', function () { expect(suiteWideFoo).toEqual(0); }); });
  20. Spies - Matchers JASMINE ANATOMY • toHaveBeenCalled() • toHaveBeenCalledWith() •

    andCallThrough() • andReturn() • andThrow() • andCallFake()
  21. You should not be afraid to delete tests that are

    no longer providing value, no matter whether you originally planned to keep them or not. We tend to treat tests as these holy creatures that live blameless, irreproachable lives once they have sprung into existence. ! Not so. ! The maintenance required to keep a test running weighs against its value in further development. Sometimes these lines cross, and the test simply becomes a burden on the project. Having the skill and experience to recognize a burdensome test is something we should be bringing to our clients, as well as the fortitude to rewrite it, rethink it, or delete it. ! - Adam Milligan