@BERMONPAINTER TEST FRAMEWORK SHOWDOWN

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

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

Unit Tests TESTS. LOTS OF TESTS. ENSURE YOU BUILD THE THING RIGHT

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

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

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

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

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

TDD TDD vs BDD

TDD TDD vs BDD 1. Write tests

TDD TDD vs BDD 1. Write tests 2. Tests fail

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

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

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

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

BDD TDD vs BDD

BDD TDD vs BDD 1. Establish goals/vision

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

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

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)

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

The hardest single part of building a software system is deciding precisely what to build. ! - Fred Brooks

No content

BEHAVIOR DRIVEN DEVELOPMENT FRAMEWORK

No content

No content

No content

No content

No content

JavaScript JASMINE ANATOMY function helloWorld() { return “Hello World!”; }

Suites JASMINE ANATOMY describe (“Hello World”, function(){ ! . . . ! });

Specifications JASMINE ANATOMY describe (“Hello World”, function(){ it(“Says hello to everybody”, function(){ . . . }); });

Matchers JASMINE ANATOMY describe (“Hello World”, function(){ it(“Says hello to everybody”, function(){ expect(helloWorld().toEqual(“Hello world!”)); }); });

Matchers JASMINE ANATOMY • expect() • toEqual() • toBeTruthy() • toBeFalsy() • toContain() • toBeDefined() • toBeUndefined() • toBeLessThan() • toBeGreaterThan() • toMatch()

No content

Utilities JASMINE ANATOMY • beforeEach() • afterEach()

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']); }); });

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); }); });

Spies JASMINE ANATOMY

Spies - Matchers JASMINE ANATOMY • toHaveBeenCalled() • toHaveBeenCalledWith() • andCallThrough() • andReturn() • andThrow() • andCallFake()

Example

Writing Specs BENEFITS & BEST PRACTICES TO GET THE MOST OUT OF JASMINE & BDD

Improve team communication BENEFITS

Encourages discussions among all team members BENEFITS

Better integration & acceptance testing BENEFITS

Describe specs, not a sequence of actions BEST PRACTICES

Keep specs at a high level BEST PRACTICES

Hide complexity in the implementation of the specs BEST PRACTICES

Test the most important/risky pieces of the system first BEST PRACTICES

Write tests until the remaining risk isn't worth the time & money to address BEST PRACTICES

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

Fin. @BERMONPAINTER