A colleague wrote:
I have a client who needs to convince their old-school management that unit testing has value. I know. I know.
and he got some good material to work off. I myself recalled a very interesting session on CITCON in Budapest where a person playing the role as CTO asked us all to convince him that they needed pre-production tests (such as unit tests). Their (the company’s) experience was that they were doing absolutely fine without it, since they had close collaboration with the customer throughout the development process and lots of eye balls looking at hourly reports on how their web site(s) performed in terms of business.
In the rare cases where a bug went through and caused “damage”, the sales and support people had turned the unfortunate events (such as selling some Gucci or Versace type of bags for 1£ each, instead of 1000£ because of an unexpected comma (thousands delimiter) in the in-data file) to something positive and a marketing “event” kind of thing. These kinds of things, bugs/errors, didn’t happen very often at all and their customer base were actually mostly positive about when it did happen as they saw a company that in very short time responded to customer feedback, were open and honest about what they did to correct the situation etc. They had lots of in-production metrics/monitoring in place and people that closely monitored their systems. From a tech point of view, they seemed to have 0 issues. Business was happy with time-to-market etc.
The session was titled Do_we_need_tests_on_planet_retail? but no-one seems to have taken notes (or at least post them). Essentially, in this case we concluded that the only valid reasons to spend time writing pre-production tests were:
We tried to pursue the argument that “tests/regression test suites” documents expected behavior of the system and helps people new to the code base not break features. Being strict with pair programming and not touching new areas without pairing with an “old timer” would ideally solve that too (and they didn’t have problems retaining their personnel). Risk obviously is a factor, “X people gets hit by a bus”-scenarios and such.
Teams of about 20 people in total doing development and ops. More people on community facing activities and sales. I understood they bought assets from companies that had gone bankrupt, and sold the stuff on-line. They’d been doing that for several years and were very profitable. Most of the work seemed to setup web sites and/or campaigns targeting certain audiences (high profile/expensive jewelery, football fans, 2013 Olympics Gadgets, …) and get statistics out of that to see how profitable the bought set of assets turned out to be. As such they monitored, from a businesses point of view, the system closely to see how the market responded to various on- and off-line activites and events.
I wouldn’t personally want to have my evenings with the kids depend on on that (systems with zero pre-production tests) but if/when what what you’re doing is mostly routine (similar things had been done many times) the value of writing the same tests over decreases as they become assertions of not typing the wrong thing. Good pair programming should save you from most of that.
TDD:ing in order to design the code, perhaps differently from previous iterations, is another subject. But in short – since the business was happy with what they were getting, and the developers lead happy lives too, it was hard to find reasons for them to have to change.