There is such thing as too much testing

The Tour

The Dealer Portal

small project (6 devs/5 months)

webunit tests

a lot of them

slow build (15-20 minutes)

WebSphere

a bit heavy

The Huge Financing App

21% coverage, 25% 4 years later

test hostile world

EJBs 1.0 shit

test suite

8 computers 36 hours

80% of these tests failed!

they didn't know why they did run them

it probably made poeple in the company feel better

The IP Space Manager

Ruby/Rails project

Government

The Small Social Start-up

Extensive Selenium testing

bulletproof app

not so good if your doing it just to test if it works in the userspace

The Social Behemoth

if you write a spike do not start building on top of that

even managers could write some code

only 50% of the team (consultants) wrote tests

us versus them philosophy

they saw tests as impediment

0 - 50% coverage

The VOIP Signup App

very high quality demanded

RoR

ridicilously well-tested code

The Social Behemoth Part II

60% coverage

SQuiD

No view testing

No integration testing

Right for the project - had to be out of the door really quickly!

The Social Behemoth Part III

Above 90% coverage

What's the Right Level of Testing

From the code's point of view

Testing is supposed to be about good design

Tests (integration tests especially) should be catching bugs

From the team's point of view

What's the level of developer buy-in for testing

morale problems

gridlock, poor velocity

What's the level of buy-in for managers

From the application's point of view

What level of assurance does it need?

Somebody looses money

Someone looses life

Someone have to fill the form second time

Lessons Learned

Start small if the team is new to testing

Selenium/watir tests are deceptively easy to get into but hard to maintain

Integration tests can replace unit tests if you're not careful

It is supreme importance to keep your test suite fast and reliable

Slow suites

Devs won't check in near end of day

Spend a lot of time on twitter

Start to see the test as an obstacle

Fix it

Parallelize

Run on a fast machine or in the cloud

Stop hitting external services or database

Profile your suite and examine slow tests

Remove redundant tests

Unreliable test suites

Team will stop caring about fails

Devs stop wondering what caused the fail and 'fix' the build in bad ways