XP practices are derived from values. In particular, there are two development practices which are related:

1. Test-first Programming (TDD)
2. Incremental Design

In this problem set you will focus on the two programming practices outlined above; TDD and incremental design. Before you continue reading this description, can you list which of the 5 values (there may be more than one for each) are used for these practices?

If you would like to read about this (on your own time) please read Chapters 6 and 7 in Extreme Programming Explained: Embrace Change by Kent Beck. We will do our best to learn the Values, Principles and Practices of XP through experience, but additional reading around theory never hurts.

This may look familiar:

Since you are writing the tests before the implementation, how does your overall approach change? Do you inspect the wireframes any differently? Do you use the information on the wireframes differently?

One way to start down the path of TDD is in plain English. The template to work with, for acceptance tests, is Given/When/Then. For example,

Open up a blank text file and with your pair write a sentences like: "Given a user is on the home page, When a user clicks on the 'Let me see right now' link, Then they see the albums index view". Start by just getting it down in a stream of conscious way as you discover features. Once you have a reasonable list to start from, devise a plan of attack around themes that arise from your document.

Image provided by: http://hanwax.github.io

Your modus operandi is "Red, Green, Refactor". Before continuing or starting to code, can you list out the steps you and your pair will follow as you use TDD? As you implement tests (and code), follow the steps you have outlined until they become second nature. Until that point, rigorously refer to the steps and police each other on it.

Again you are free to use whatever libraries you would like so long as Express is the base framework used.

For this exercise, we are building a universal library of music albums. In this case, imagine that the library itself is crowd sourced, so we allow users to create new albums, delete albums, etc.

These wireframes give a sketch of how the application should work. Hint: Pay attention to the URLs.

1. Use the express . command to create an empty skeleton in this directory.
2. Run npm install to import dependencies.
3. Run npm install --save-dev chai protractor to add test dependencies.
4. Run npm install --save monk to read from the database.
5. Create /test/conf.js (from Protractor tutorial):

exports.config = {
  specs: ['acceptance/*.js'],
  framework: 'mocha',
  mochaOpts: {
    reporter: 'spec',
    slow: 3000,
    enableTimeouts: false
  },
  capabilities: {
    'browserName': 'chrome'
  },
  directConnect: true
};

1. Create test/acceptance/album_test.js (from Protractor tutorial):

var http = require('http');
var expect = require('chai').expect;
var app = require('../../app');

before(function() {
  var server = http.createServer(app);
  server.listen(0);
  browser.baseUrl = 'http://localhost:' + server.address().port;
  browser.ignoreSynchronization = true;
});

describe('Express CRUD', function() {
  describe('Given I visit /users', function() {
    it('Then I see the express default', function() {
      browser.get('/users');
      element(by.tagName('body')).getText().then(function(text) {
        expect(text).to.equal('respond with a resource');
      });
    });

  });
});

1. Complete the CRUD application from the provided wireframes using TDD. For acceptance tests use Protractor. For unit tests use Mocha with Chai.
2. Use Git to commit your new application and push it to a remote repository (either your fork of this problem set or a new repository).
3. [stretch] Use sinon to mock express and monk to write unit tests for your routes.
4. [stretch] In Agile software development, it is important to understand who the users of a system are. As we will see later on, a way to do this is to define a set of personas who are basically the users of our system (aka humans). For this exercise we have two personas:
5. Gary the Guest - Gary is a music fan who has never visited the "OMG Albums!" application before.
6. Mary the Music Lover - Registered user of the "OMG Albums!" application, she loves music and regularly uses the album catalogue.

An Agile User Story outlines for developers what behaviors the users of a given system would like to have. We will go over this in depth, for now the goal is to gain exposure to the language of stories. Implement the following user stories:

1. As Gary, I would like to be able to Sign Up by clicking a sign up link on the home page, so that I can use the "OMG Albums!" application to store my favorite albums.

_Acceptance Criteria_:
1. Given that I am Gary on the home page, when I click "Sign Up", then I am taken to `/sign-up` and provided a form to register with my email and a password. _Note:_ For this story, do not worry about email or password validations.

1. As Mary, I would like to select albums on the index view (/albums) to be favorites by clicking on a star (or other icon) next to the name, so that I can easily toggle and identify which albums I like.

_Acceptance Criteria_:
1. Given I am Mary visiting `/albums`, when I click on the icon next to the name of an album, then the album is recorded as a favorite in the database and the icon changes to indicate that the album is a favorite. _Note:_ The page should not refresh.
1. Given I am Mary visiting `/albums`, when I click on the icon next to the name of an album that is already a favorite album, then the album is removed as a favorite in the database. _Note:_ The page should not refresh.

1. As Mary, I would like to have a page showing my favorite albums, so that I can keep track of music I enjoyed listening to.

_Acceptance Criteria_:
1. Given that I am Mary visiting `/albums`, when I click on the "Favorites" link, then I am taken to `/favorites` and shown a listing of my favorite albums.

1. [epic stretch] Now that you have implemented user registration and authentication, what kind of features would we expect to add? Although there are many answers, we will focus on a common problem; authorization. For this part of the exercise, use the provided written description and write your own user stories:

2. When Gary attempts to visit any path that includes /albums (e.g. /albums/new), they are redirected to / and told to login before visiting that path. Are there any other paths for which this should be the case?

As always, stop a few minutes before the end of the day and, working with your pair, answer the following questions:

1. What is the relationship between acceptance criteria and acceptance testing?
2. How many times did you have to open the application in the browser to verify that something actually worked but didn't in your test?
3. Of the sentences you may have begun with, how many ended up in your final documentation? (the output of the test run)
4. What is the connection between Test Driven Development and Error Driven Development?
5. Give each other two pieces of praise based on your work together for the day. Examples of this are things like "you did an excellent job catching syntax errors while I was driving, it made me feel like you were highly engaged in solving the problem with me." or "you did a great job communicating what you were thinking and checking in with me to see if we agreed before we moved forward."