TripCase Unit Testing with Jasmine

TripCase Unit Testing with JasminePresented by Steve Pond @stephenpond

Tuesday, December 11, 12

Overview

What to Unit Test?

Test Driven Development

Walkthrough of Jasmine Unit Testing and Tools

Walkthrough of JSCover - coverage testing

Q & A


Unit TestingRepeatable: You can rerun the same test as many times as you want.

Consistent: Every time you run it, you get the same result. (for example: Using threads can produce an inconsistent result)

In Memory: It has no “hard” dependencies on anything not in memory (such as file system, databases, network)

Fast: It should take less than half a second to run a unit test.

Checking one single concern or “use case” in the system: (More than one can make it harder to understand what or where the problem is when the problem arises.)


Integration TestingUse system dependent values that change dynamically (such as DateTime.Now, or Environment.MachineName)

Create objects of which it has little control (such as threads, random number generators)

Reach out to external systems or local machine dependencies (from calling web services to using local configuration files)

Test multiple things in the course of one test case (from database integrity, to configurations, to protocols, to system logic, in one go).


What to Unit Test?


Framework implements multiple libraries

Inner-team dialogues are generally integration related

Deadline Driven. Zero time.

GreenField - BrownField

TripCase UT Barriers


ProcedureDetermining what is unit-testable


ReflexiveDoes its own thing... (extension to our app’s core logic)


AlgorithmicOur apps consciousness, makes decisions, etc...


TripCase Analysis

Core

Router

Views

Controller

Workflows

Model/Collection


Core

Heartbeat

Sets up Require config

app.js

Initializes app modules


Core - Reflexive

Mainly just initialization

Launching the App


Router

History Stack

Navigation API

Map hash change to mediator events & vice versa


Router - Reflexive

Mainly just mapping hash changes to mediator events

API, and history stack, handed to us


Views

Views present model data and respond to client interactions

Ideally, views just render and invoke actions on the model


Views - Reflexive

Views merely couple the model and the client interaction

Up for debate: some success/fail scenarios sometimes handled in view? Sounds Algorithmic.

Use discretion on Unit Testing


Controllers

Module/Feature level, initializes the workflow or view

Workflow handles app state change, swaps views

Controller listens to mediator events for various action

Listens to view/workflow level events


Controller - Reflexive

Workflows should be kept lean (refer to SOLID principle) and stick to single responsibility rule

Controllers mainly just mapping the mediator to workflow or view initializations

In practice, I have seen a lot of app logic handled in workflows. Unit Test with discretion.


Models

Sync, fetch, and Save

Special parsing

Special validation

Special helpers

Special URL and payload


Models - Algorithmic

Models/ Collections - clear choice for unit test candidates

We provide a lot of logic for parsing and helpers here


Next Step: Draft our spec

Analyze a story

Pseudo Code


Analyze Story: Share Itinerary

Contacts Collection

Share contacts helper should return all contacts that are shared

Contacts model

Should properly construct a URL for syncing

Should properly construct a payload for fetching

Should properly construct a payload for saving

Should properly validate user Input

Should properly set attributes for a given response


Test-Driven Development


Ken Beckwho is credited with having developed or 'rediscovered' the technique, stated in

TDD encourages simple designs and inspires

confidence.


A Simple TDD Workflow 1.Write test stubs based on business requirements for a new feature 2.Write minimal code in Spec to PASS the unit test 3.Tweak code to pass the FUNCTIONAL test 4.Go back and tweak the unit test with new code and Together until SUCCESS


Group Activity: Analyze a Story

Given the story of a Search Hotel Module, identify the unit-testable assertions

Apply it to a minimal Jasmine Spec Template


Jasmine Basics


Jasmine Basics - Blocks


Jasmine Basics - Setup/Teardown


Jasmine Basics - Spies


Jasmine Basics - Sinon(not really unit-testing, but useful for integration testing)


Walkthrough


Date post:	16-May-2015
Category:	Documents
Upload:	stephen-pond
View:	702 times
Download:	2 times

TripCase Unit Testing with Jasmine

Documents