TripCase Unit Testing with Jasmine
2 likes731 views
The document discusses a presentation about unit testing TripCase with Jasmine. It covers an overview of unit testing and what parts of an application are best suited for unit testing. It then discusses the specific challenges of unit testing TripCase and analyzes which parts of TripCase are reflexive and algorithmic and therefore good candidates for unit testing. It also covers test-driven development and includes an example of identifying unit test assertions for a hotel search story.
TripCase Unit Testing with Jasmine
- 1. TripCase Unit Testing with Jasmine Presented by Steve Pond @stephenpond Tuesday, December 11, 12
- 2. Overview What to Unit Test? Test Driven Development Walkthrough of Jasmine Unit Testing and Tools Walkthrough of JSCover - coverage testing Q&A Tuesday, December 11, 12
- 3. 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
- 4. 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
- 5. What to Unit Test? Tuesday, December 11, 12
- 6. TripCase UT Barriers Framework implements multiple libraries Inner-team dialogues are generally integration related Deadline Driven. Zero time. GreenField - BrownField Tuesday, December 11, 12
- 7. Procedure Determining what is unit-testable Tuesday, December 11, 12
- 8. Reflexive Does its own thing... (extension to our app’s core logic) Tuesday, December 11, 12
- 9. Algorithmic Our apps consciousness, makes decisions, etc... Tuesday, December 11, 12
- 10. TripCase Analysis Core Router Views Controller Workflows Model/Collection Tuesday, December 11, 12
- 11. Core Heartbeat Sets up Require config app.js Initializes app modules Tuesday, December 11, 12
- 12. Core - Reflexive Mainly just initialization Launching the App Tuesday, December 11, 12
- 13. Router History Stack Navigation API Map hash change to mediator events & vice versa Tuesday, December 11, 12
- 14. Router - Reflexive Mainly just mapping hash changes to mediator events API, and history stack, handed to us Tuesday, December 11, 12
- 15. Views Views present model data and respond to client interactions Ideally, views just render and invoke actions on the model Tuesday, December 11, 12
- 16. 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 Tuesday, December 11, 12
- 17. 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 Tuesday, December 11, 12
- 18. 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
- 19. Models Sync, fetch, and Save Special parsing Special validation Special helpers Special URL and payload Tuesday, December 11, 12
- 20. Models - Algorithmic Models/ Collections - clear choice for unit test candidates We provide a lot of logic for parsing and helpers here Tuesday, December 11, 12
- 21. Next Step: Draft our spec Analyze a story Pseudo Code Tuesday, December 11, 12
- 22. 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 Tuesday, December 11, 12
- 23. Test-Driven Development Tuesday, December 11, 12
- 24. TDD encourages simple designs and inspires confidence. Ken Beck who is credited with having developed or 'rediscovered' the technique, stated in Tuesday, December 11, 12
- 25. 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 Tuesday, December 11, 12
- 26. 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 Tuesday, December 11, 12
- 27. Jasmine Basics Tuesday, December 11, 12
- 28. Jasmine Basics - Blocks Tuesday, December 11, 12
- 29. Jasmine Basics - Setup/Teardown Tuesday, December 11, 12
- 30. Jasmine Basics - Spies Tuesday, December 11, 12
- 31. Jasmine Basics - Sinon (not really unit-testing, but useful for integration testing) Tuesday, December 11, 12