| Time | Topic |
|---|---|
| 1:00-1:30 | Intro: background, goals, first steps |
| 1:30-2:15 | Exercise: Simple tests, simple test runner |
| 2:15-2:30 | Discussion: types of tests |
| 2:30-2:45 | Break |
| 2:45-3:45 | Exercise: Node.js web service, Grunt-based integration & unit test runner |
| 3:45-4:00 | Discussion: Intro to lineman, testem, browser testing |
| 4:00-5:00 | Exercise: Lineman.js web app, Testem test runner |
Goal: set expectations and provide a context for the day
- Set agenda, goals, and constraints
- Solicit requests from attendees of concepts to emphasize or cover ad hoc
- Review vanilla Jasmine API briefly
- Review the jasmine-given CoffeeScript API
Goal: practice the rhythm and rules of red-green-refactor; understand how simple Jasmine really is (as a script you drop into a plain HTML page)
- Provide a pre-packaged standalone runner with CoffeeScript script tag support added
- Pair off and do the Roman Numeral Kata in a 30 minute time box
- Do a short retrospective afterward
Goal: discuss how to use TDD to break a large problem down. Use a Node.js example to demo outside-in TDD in a familiar domain (HTTP controller actions) to Rubyists
- Explain the limitations of basic TDD and introduce concepts from GOOS and a reductionist approach
- Introduce Node.js and basic necessary concepts (Common JS packages, etc.)
- Demo grunt, grunt-jasmine-bundle, node-sandboxed-module to break down a large problem into a small one
Goal: practice outside-in TDD, gain familiarity with Node and one way to write tests in Node.
- Students start with a failing integration test
- Starting with an express.js app, break down a nice object model that creates arithmetic quiz questions and accepts solutions
Rules of the game:
- Practice outside-in TDD to break the problem down into multiple units, multiple files.
- Create a "GET /problem" route, which will generate a new ID, create a random (easy) arithmetic problem (e.g. "10 ÷ 2") and store it with that ID in memory, return a structured object back that a user interface could work with
- Create a "GET /problem/:id" route by which a problem can be revisited or shared
- Create a "POST /solution" which takes a problem ID and an answer, responding with a 422 if the solution is incorrect & a 202 if the solution is correct
Goal: Familiarize the class with the front-end web tooling we recommend for fat-client JavaScript applications, set expectations about practicing TDD in the presence of an application framework
- Discuss Client/Server separation, why we built Lineman to make that easy to accomplish
- Demonstrate Testem and how it's totally awesome.
- Illustrate how application frameworks and TDD both try to solve the same problem: how to prevent code from becoming an unreasonable mess.
- Identify some of the tensions that inevitably arise from attempting TDD in a large framework
- Discuss creating scar tissue for application frameworks and wrappers for third-party dependencies
Goal: Practice some of the more challenging tactics useful when testing DOM interactions, with less of an emphasis on TDD's design benefits.
Rules of the game:
- No application frameworks (e.g. Angular, Backbone, Ember), but heavy convenience libraries like jQuery are okay
- TDD a web interface to the math quiz service that we started in the previous exercise: render a problem and a response form, POST attempted solutions, give the user feedback, and move on to new problems
- Use the tactics we learned when tackling legacy jQuery to aggressively push new abstractions with outside-in TDD, building scar tissue between the application and the browser
[Note: the rule above not to use an application framework does not indicate a negative opinion about application frameworks, but rather that they pose a number of additional time-consuming challenges when practicing TDD, which we'll discuss as a group.]