"You have 40 bowls, all placed in a line at exact intervals of 1 meter. You also have 9 oranges. You wish to place all the oranges in the bowls, no more than one orange in each bowl, so that there are no three oranges A, B, and C such that the distance between A and B is equal to the distance between B and C. How many ways can you arrange the oranges in the bowls?."

"An Informative Build is a build that tells us what the state of our development is so that we can make an informed decision. We need an informative build, because otherwise Continuous Integration is just a waste of our time.

That’s right, I said Continuous Integration is a waste of time. It is a waste of time, because simply running a build doesn’t help us unless that build can also tell us what we need to do. An Informative Build:

Fails when something is wrong, letting us know that our system is broken and we must fix it.
When it fails it tells us precisely why it failed so that we know what we have to do to fix it.
When nothing is wrong it doesn’t fail. We shouldn’t be wasting cycles chasing down errors due to brittle tests or external dependencies."

"Things to keep in mind.

No matter where you start, start with one simple test. One assertion, if you can manage it.
Write the code to make that test pass
Then refactor -- this part is critical, this is where the creative design is with a TDD process.
Then write the next test.
In Rails, you'll often start in the controller then realize that code needs to be written in the model (or vice-versa). Write a separate test for the model -- testing models from the controller makes it hard to test all the model logic.
It's okay to plan the tests in advance, but you should only work on one test at a time. (Sometimes I'll write the series of tests, then comment out all but one)"

"Machinist generates data for the fields you don't care about, and constructs any necessary associated objects, leaving you to only specify the fields you do care about in your tests."

"We’ve been writing a “feature” for every new client request on that project – for each user-created ticket we handle, we create a .feature file (and include the ticket number in the feature title), and write steps for that request. This means that we have acceptance tests for all new client requests on that project. This approach may seem a little strange, but it’s been helpful, and we’re very happy with it so far. We’ll likely take a different approach if we use Cucumber on a project from scratch.

Now you have no excuse if your projects aren’t doing any kind of top-down testing, so get out there and write some acceptance tests!"

"The Shoulda gem makes it easy to write elegant, understandable, and maintainable Ruby tests. Shoulda consists of test macros, assertions, and helpers added on to the Test::Unit framework. It’s fully compatible with your existing tests, and requires no retooling to use."

Great TDD kata from UncleBob. Unfortunate it's PowerPoint; would be nice if it were a PDF. But it's legible.