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.]