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/

1. @BERMONPAINTER TEST FRAMEWORK SHOWDOWN
2. Types of Tests TESTS. LOTS OF TESTS. • SMOKE TESTS • INTEGRATION TESTS • USER ACCEPTANCE TESTS • REGRESSION TESTS • UNIT TESTS
3. Types of Tests TESTS. LOTS OF TESTS. • SMOKE TESTS • INTEGRATION TESTS • USER ACCEPTANCE TESTS • REGRESSION TESTS • UNIT TESTS
4. Unit Tests TESTS. LOTS OF TESTS. ENSURE YOU BUILD THE THING RIGHT
5. Unit Tests TESTS. LOTS OF TESTS. ENSURE YOU BUILD THE THING RIGHT • code functions as designed
6. Unit Tests TESTS. LOTS OF TESTS. ENSURE YOU BUILD THE THING RIGHT • code functions as designed • run when code it compiled
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
8. 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
9. 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
10. TDD TDD vs BDD
11. TDD TDD vs BDD 1. Write tests
12. TDD TDD vs BDD 1. Write tests 2. Tests fail
13. TDD TDD vs BDD 1. Write tests 2. Tests fail 3. Write code
14. TDD TDD vs BDD 1. Write tests 2. Tests fail 3. Write code 4. Tests pass
15. TDD TDD vs BDD 1. Write tests 2. Tests fail 3. Write code 4. Tests pass 5. Refactor
16. TDD TDD vs BDD 1. Write tests 2. Tests fail 3. Write code 4. Tests pass 5. Refactor 6. Repeat
17. BDD TDD vs BDD
18. BDD TDD vs BDD 1. Establish goals/vision
19. BDD TDD vs BDD 1. Establish goals/vision 2. Involves team to describe the behavior of an app.
20. 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
21. 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)
22. 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
23. The hardest single part of building a software system is deciding precisely what to build. ! - Fred Brooks
25. BEHAVIOR DRIVEN DEVELOPMENT FRAMEWORK
31. JavaScript JASMINE ANATOMY function helloWorld() { return “Hello World!”; }
32. Suites JASMINE ANATOMY describe (“Hello World”, function(){ ! . . . ! });
33. Specifications JASMINE ANATOMY describe (“Hello World”, function(){ it(“Says hello to everybody”, function(){ . . . }); });
34. Matchers JASMINE ANATOMY describe (“Hello World”, function(){ it(“Says hello to everybody”, function(){ expect(helloWorld().toEqual(“Hello world!”)); }); });
35. Matchers JASMINE ANATOMY • expect() • toEqual() • toBeTruthy() • toBeFalsy() • toContain() • toBeDefined() • toBeUndefined() • toBeLessThan() • toBeGreaterThan() • toMatch()
37. Utilities JASMINE ANATOMY • beforeEach() • afterEach()
38. 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']); }); });
39. 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); }); });
40. Spies JASMINE ANATOMY
41. Spies - Matchers JASMINE ANATOMY • toHaveBeenCalled() • toHaveBeenCalledWith() • andCallThrough() • andReturn() • andThrow() • andCallFake()
42. Example
43. Writing Specs BENEFITS & BEST PRACTICES TO GET THE MOST OUT OF JASMINE & BDD
44. Improve team communication BENEFITS
45. Encourages discussions among all team members BENEFITS
46. Better integration & acceptance testing BENEFITS
47. Describe specs, not a sequence of actions BEST PRACTICES
48. Keep specs at a high level BEST PRACTICES
49. Hide complexity in the implementation of the specs BEST PRACTICES
50. Test the most important/risky pieces of the system first BEST PRACTICES
51. Write tests until the remaining risk isn't worth the time & money to address BEST PRACTICES
52. 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
53. Fin. @BERMONPAINTER