[TIP] Web Application Testing Code of Ethics?

Ben Finney ben+python at benfinney.id.au
Thu Nov 20 20:26:08 PST 2008

"C. Titus Brown" <ctb at msu.edu> writes:

> On Fri, Nov 21, 2008 at 09:40:54AM +1100, Ben Finney wrote:
> -> "C. Titus Brown" <ctb at msu.edu> writes:
> -> > "Test your shit, or I breaka your head".
> -> 
> -> Not measurable. Things that get measured tend to get done more
> -> reliably.
> Actually, I disagree -- processes that get measured to get done in
> such a way that the measurement improves, but that's all.

We're not in disagreement. All I'm claiming is that the thing that is
measured is what will be done more reliably, and that “do it right or
else” doesn't actually ask for anything measurable at all.

There remains, of course, the problem of picking something to measure
that has a high correlation to the result one actually wants.

> There is, IMO, no substitute to having the developers actually
> devoted to producing Good Stuff. How to do that is the trick, and I
> don't think there's a one-size-fits-all solution. Certainly there's
> no silver bullet. And that's what agile (with a little 'a') is all
> about: adapting to your circumstances to produce quality products.

Indeed. I'm recommending that the demand to deliver a well-tested
application should be enforced by something measurable that has a high
correlation with that result: and I'm proposing a full test suite that
demonstrates the correct functionality as something that is far better
for this purpose than nothing measurable at all.

You are quite correct that this doesn't solve the entire problem, but
it does inculcate a shift toward the right mindset. More importantly,
in my view, it makes clear at the *start* of the development process
that testing is not something to be paid mere lip service and
postponed beyond the point where the budget has run out, but rather
that *demonstrable, automated testing is a necessary part of
delivery* and the delivery isn't accepted without that.

If, at that early point, you find that the developers balk at the idea
of routinely presenting automated, demonstrable assertions of
correctly-functioning applications, then this is a problem to be
addressed with those developers or raised with whoever is responsible
for enforcement at the outset, rather than something to be only
discovered after all the development work has been done.

> Since I am a mean SOB, in Noah's friend's situation I would
> simply... deploy the code that had been given to me. At 4:55pm on a
> Friday. And then go home for the weekend and turn off my pager.

This results only in finger-pointing; I'm proposing rather something
that exposes problems earlier and allows them to be addressed
constructively at that point.

> p.s. Get me to buy you a drink at PyCon and I'll tell you about my
> experiences with introducing automated test in my sophomore/junior
> UG class...

An attractive proposition, but I'll have to be honest and say it's
unlikely I'll be attending PyCon in the foreseeable future. If you're
ever in Melbourne then there's a higher likelihood of taking you up on
the offer :-)

 \         “True greatness is measured by how much freedom you give to |
  `\      others, not by how much you can coerce others to do what you |
_o__)                                               want.” —Larry Wall |
Ben Finney

More information about the testing-in-python mailing list