At Songza, we're very much into testing.  Our test suite currently has over 600 individual test cases, with new tests getting written almost every day.

A test is useless if it doesn't get run, and people being human, if it's a pain to run a test, they won't run it. That means tests have to be fast.  Over time, we've been working on speeding up our tests, mostly by ferreting out some truly horrendous inefficiencies in how fixtures are constructed. We've gone from having maybe 100 tests that took 5-10 minutes to run, to ...

In an earlier installment, I wrote, I don't quite understand why, but most programmers don't like testing.  I also hinted that I wasn't completely clueless about the reason.  It's really quite simple.  Their employers tell them that writing software is more important than testing it.  Sure, at the all-hands meetings, some VP will get up there and drone on about how we're all part of the team, and everybody is important in their own way.  Comes payday, however, the message is loud and clear.

I just took a quick look on glassdor.com for engineers ...

As the saying goes, test happens. Sometimes it happens because the developer writes and runs the tests at the same time he's writing the code. When this happens, bugs get found quickly. And they fixed quickly, when it's cheap and easy. Life is good.

Sometimes, it happens when the code gets thrown over the wall to the QA department. This might be a few days later. In some shops, it might be weeks or months later. By that time, the developer who wrote the bug has probably forgotten everything about the code and has to spend time getting ...