There is a value in writing tests and there is also a cost. The currency is time. The trade-offs are difficult to evaluate because the cost and value are often seen by different people. The writer of the test bears much of the short term cost while long term benefits and cost are borne by the rest of the team. By planning around both the the cost and value of your tests, you’ll improve your tests and your code.

There is a value in writing tests and there is also a cost. The currency is time. The trade-offs are difficult to evaluate because the cost and value are often seen by different people. The writer of the test bears much of the short term cost while long term benefits and cost are borne by the rest of the team. By planning around both the the cost and value of your tests, you’ll improve your tests and your code.

Test doubles (which you may know under the alias “mock objects”) are the most misunderstood and misused testing tools we've got. Starting with the fact that nobody can agree on what to call them. Contrary to what you may have heard, test doubles do not inherently lead to fragile tests.

"Red. Green. Refactor" is a great slogan for Test-Driven Development. It's less great as a guide to actual TDD practice. The slogan provides no guidance for two very important questions in a TDD process: "What do I test next?" and "How do I break my problem into testable pieces".

RSpec is often described with the word “magic” by both its users and its detractors. Understanding how RSpec matchers, doubles, and specifications work will help you as an RSpec user. You will be able to take advantage of RSpec’s flexibility to make your tests clearer and more expressive. You’ll also get some exposure to new RSpec features, like compound matchers.

In this workshop, we'll focus on two specific problems that plague testing complex systems: how do I create useful test data, and how do I limit my test to only the part of the system that I want tested. We'll cover data creation tools like factories and fixtures. We will also talk about how to effectively use mock objects. And we'll do all that against some code that shows off potental testing problems.

I don't think I'm alone in being drawn to TDD at first because it was fun. The quick and consistent feedback and the ability to turn complicated problems into a series of smaller problems to be solved made TDD development seem more like a game than work.

Another talk about the mechanics of testing. Introducing the tortured acronym SWIFT for the five habits: Simple, Well-Defined, Independent, Fast, Truthful

Everybody wants to do test-driven development, but switching to TDD or BDD on an existing project that doesn't have tests presents special challenges. Often, the current code is a tangled mess of dependencies that defeats the very concept of unit testing. Worse, if somebody has attempted TDD in the past, you might have a test suite that needs to be fixed before any new tests can be written.