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