Description:

Your project's software practices are deteriorating every minute the developers wait for slow tests to finish. Once developers get fed up and stop running the tests, disregard for failing builds can't be far behind, and from there it's only a short leap to the albatross of a brittle/irrelevant test suite. Luckily this can all be avoided by adopting some time-saving testing standards and practices.

If everyone knows that test suites should be fast then why do they take so damn long? Some of that is lack of knowledge about what’s fast and what is not, but mostly the problem is lack of awareness of 2 things:

1. When you write tests you should be thinking about their speed.
2. A test that needs lots of setup is telling you something: Your object sucks.

Test suites usually grow and stumble along without too much thought. “Hey thing X looks shiny, let’s add that in.” is about as far as the process often goes. You need to architect your test suite just like any other part of your code. This does NOT mean lots of meetings and UML diagrams, but adopting a set of team testing guidelines and practices. And, of course, communicating those guidelines and practices to new developers.

Some topics I’ll be discussing:

• Big Setup == Big Problem
• before :each {waste_my_time}
• FactoryGirl is too damn awesome
• The extra tricky test suite
• Just because mocking can solve some of your problems…
• Use all your cores, damnit

I’ve been on 10 projects with automated tests in the last 6 years and I’ve seen speedy confidence inducing suites and others that only served to make developers feel dread and guilt about testing. The point of this talk is to communicate tangible strategies for speedily testing Ruby.