<div>If we go back to 1999 - so I was the Chief Technical Architect at <a href="http://if.com">if.com</a> and we spend $100m on technology.</div><div><br></div><div>We didn't have ANY tests at all. What we did have was a testing team of I suppose 35 full time testers and varyingly dozens to hundreds on secondment.</div>
<div><br></div><div>If you were in the business of consuming software (unlike Ericsson) you didn't have kit lying around.</div><div><br></div><div>If you split out your code base into components that are pure functions (unit testable) and components that have side effects (system testable) you can build good test case coverage into your dev process. But if you are an n-tier architecture in imperative/OO languages with side-effects in almost all modules you can only do system tests.</div>
<div><br></div><div>If you are a n-tier application (web server/Java mid-tier/mainframe backend) no developer has access to a machine that is capable of running 'the system' - so automatic system testing is simply impossible - it is not possible write them, let alone run them many times a day.</div>
<div><br></div><div>So what you end up with is a monolithic user testing process (at <a href="http://if.com/Halifax">if.com/Halifax</a> it was 12 weeks end to end MINIMUM from developers desktop to production) with 6 major testing gates and you beat the software into submission.</div>
<div><br></div><div>If you look at us now at Vixo (formerly Hypernumbers) we have a BFN* of tests and we can release from dev to production many times a day.</div><div><br></div><div>The reason for this is that:</div><div>
* most of our code is side-effect free and is built backwards from tests - you write a test suite and tinker about until the module passes them all</div><div>* everyone has full access to a machine which has near production performance (ie a laptop)</div>
<div><br></div><div>We rent boxes for a couple of hundred dollars a month that we paid capital costs of £1.5m the pair in '99</div><div><br></div><div>Testing may well have been invented years ago but it is still fairly recent in bespoke commercial software development.</div>
<div><br></div><div>Gordon</div><div><br></div><div>* BFN is the correct mathematical term for a Big Number </div><div><br><div class="gmail_quote">On 13 July 2012 13:11, Ulf Wiger <span dir="ltr"><<a href="mailto:ulf@feuerlabs.com" target="_blank">ulf@feuerlabs.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On 13 Jul 2012, at 13:04, Joe Armstrong wrote:<br>
> Since they have no specification, their can't really be any tests.<br>
> Or worse, in the absence of a specification, the tests *become* the<br>
> specification.<br>
</div>Well, in general, I'd have to take exception to this description ;-),<br>
but in the case of a markup language, pushing through without<br>
a specification is obviously asking for trouble.<br>
With common commercial development, there is very<br>
seldom a specification in any useful sense of the word. What<br>
there is, is a customer's more or less vague idea of what they<br>
want, and the reality any implementation of their idea will<br>
eventually face.<br>
In such situations, the tests *do* become the specification,<br>
because a specification *cannot* be written! If you try to write<br>
one anyway, it will seriously delay the project, and be obsolete<br>
as soon as it's finished, if it ever had a chance of being correct<br>
(it probably didn't).<br>
In other words, don't blame the designer who creates a test<br>
suite in those cases, rather than brow-beating the poor customer<br>
until they come up with a workable specification. The practice<br>
of using cue cards to write user stories (and the acceptance<br>
criteria on the back) evolved very much because it was a<br>
workable way of discussing the requirements with users,<br>
whether or not they had any engineering or science background.<br>
<a href="http://www.allaboutagile.com/user-story-example/" target="_blank">http://www.allaboutagile.com/user-story-example/</a><br>
It seems ridiculously vague and limited, but in practice, it actually<br>
helps to catch *some* of the information needed to arrive at some<br>
mutually understood acceptance criteria. This wasn't created<br>
because people didn't understand what formal specifications,<br>
or thorough testing, looked like - it was created in order to achieve<br>
at least *some* level of improvement with *real* projects and<br>
real customers.<br>
Besides, when did you last see a good specification of how<br>
a Web GUI should behave - or a good way to test it? *<br>
Another example: When I gave an invited talk at NWPT'99 [1] in<br>
Uppsala, Sweden, a member of the audience (probably a PdD<br>
student), reacted to my description of the 3-month test period<br>
before release of the AXD 301, saying "That's ridiculous! If you<br>
had written it using a language that could be formally verified,<br>
you wouldn't have to test at all!".<br>
I mumbled something about not knowing if that would have been<br>
at all possible, and Thomas Arts jumped in and offered to argue<br>
the point with him in the break. It was a very vivid discussion, as I recall.<br>
[1] <a href="http://www.it.uu.se/research/publications/reports/1999-008/nwpt99/proceedings/" target="_blank">http://www.it.uu.se/research/publications/reports/1999-008/nwpt99/proceedings/</a><br>
Obviously at that scale (for all except for that PhD student), there<br>
is no chance of arriving at a coherent formal specification, since<br>
the standards we were supposed to comply with were not<br>
themselves formally specified**, and many of the customers didn't<br>
necessarily want *exactly* what was in the standard anyway.<br>
Furthermore, many of the non-functional requirements were not<br>
specified at all, except as a more or less vague list of "goodness<br>
criteria", trying to encapsulate what it means for a system to be<br>
What we ended up with was a large pile of informal requirements,<br>
and a huge set of test cases (nearly a million lines of code).<br>
At that point, the test suites *were* indeed the real specification,<br>
albeit an extremely bulky and inaccessible one.<br>
Ulf W<br>
* One of the best is probably Cucumber (<a href="http://cukes.info/" target="_blank">http://cukes.info/</a>), which<br>
is based on cue cards, and relies on quite an ambitious mapping<br>
to the underlying web stack (e.g. Rails). Without such a mapping,<br>
it is less useful, although it still has its sweet spots.<br>
** …although some would disagree. They are certainly specified in<br>
a bureaucratic way, but that's not the same thing.<br>
<div class="im HOEnZb"><br>
Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.<br>
<a href="http://feuerlabs.com" target="_blank">http://feuerlabs.com</a><br>
</div><div class="HOEnZb"><div class="h5">_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>