• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
TripCase Unit Testing with Jasmine

TripCase Unit Testing with Jasmine






Total Views
Views on SlideShare
Embed Views



1 Embed 1

https://twitter.com 1



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.

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

    TripCase Unit Testing with Jasmine TripCase Unit Testing with Jasmine Presentation Transcript

    • TripCase Unit Testing with Jasmine Presented by Steve Pond @stephenpondTuesday, December 11, 12
    • Overview What to Unit Test? Test Driven Development Walkthrough of Jasmine Unit Testing and Tools Walkthrough of JSCover - coverage testing Q&ATuesday, December 11, 12
    • Unit Testing Repeatable: 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.)Tuesday, December 11, 12
    • Integration Testing Use 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).Tuesday, December 11, 12
    • What to Unit Test?Tuesday, December 11, 12
    • TripCase UT Barriers Framework implements multiple libraries Inner-team dialogues are generally integration related Deadline Driven. Zero time. GreenField - BrownFieldTuesday, December 11, 12
    • Procedure Determining what is unit-testableTuesday, December 11, 12
    • Reflexive Does its own thing... (extension to our app’s core logic)Tuesday, December 11, 12
    • Algorithmic Our apps consciousness, makes decisions, etc...Tuesday, December 11, 12
    • TripCase Analysis Core Router Views Controller Workflows Model/CollectionTuesday, December 11, 12
    • Core Heartbeat Sets up Require config app.js Initializes app modulesTuesday, December 11, 12
    • Core - Reflexive Mainly just initialization Launching the AppTuesday, December 11, 12
    • Router History Stack Navigation API Map hash change to mediator events & vice versaTuesday, December 11, 12
    • Router - Reflexive Mainly just mapping hash changes to mediator events API, and history stack, handed to usTuesday, December 11, 12
    • Views Views present model data and respond to client interactions Ideally, views just render and invoke actions on the modelTuesday, December 11, 12
    • 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 TestingTuesday, December 11, 12
    • 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 eventsTuesday, December 11, 12
    • 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.Tuesday, December 11, 12
    • Models Sync, fetch, and Save Special parsing Special validation Special helpers Special URL and payloadTuesday, December 11, 12
    • Models - Algorithmic Models/ Collections - clear choice for unit test candidates We provide a lot of logic for parsing and helpers hereTuesday, December 11, 12
    • Next Step: Draft our spec Analyze a story Pseudo CodeTuesday, December 11, 12
    • 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 responseTuesday, December 11, 12
    • Test-Driven DevelopmentTuesday, December 11, 12
    • TDD encourages simple designs and inspires confidence. Ken Beck who is credited with having developed or rediscovered the technique, stated inTuesday, December 11, 12
    • A Simple TDD Workflow 1. Write test stubs based on business requirementsfor 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 codeand Together until SUCCESSTuesday, December 11, 12
    • 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 TemplateTuesday, December 11, 12
    • Jasmine BasicsTuesday, December 11, 12
    • Jasmine Basics - BlocksTuesday, December 11, 12
    • Jasmine Basics - Setup/TeardownTuesday, December 11, 12
    • Jasmine Basics - SpiesTuesday, December 11, 12
    • Jasmine Basics - Sinon (not really unit-testing, but useful for integration testing)Tuesday, December 11, 12
    • WalkthroughTuesday, December 11, 12