> Sep 9 2009 5:19pm from IGnatius T Foobar @uncnsrd
>I like the idea of unit tests, but I don't understand how they can be
>applied to code which implements a user interface -- which happens to
>be where the bulk of our bugs are right now. How is that normally
>achieved?
>
>
I'm not going to lie and say it it's easy, because it's not without its
difficulties. In fact, we typically leave it to our QA department to do
the bulk of the browser testing...
But the typical approach on the server side is the MVC design pattern,
which allows you to separate your code into Model, View (user interface),
and Control (logic.) The idea is... Control and Model are the easiest
parts to test, and you try to move as much of your logic into those 2
layers as possible, and out of View. I.e., every time you write an "if"
statement, in theory you have to write at least 2 automated test cases,
one of the taken case and one for the branch-not-taken case. So you try to
keep as many of those "if" statements nicely decoupled from the View
layer, as you can.
At my previous employer, we went really apeshit and designed, in Java, a
Qt-esque object framework that was designed to generate HTML and
encapsulate all of the commonalities of our HTML generation. While I was
still there, we never got to the point where we had significant test
coverage for this layer, but I assume that the unit testing problem would
be at least somewhat easier to solve with this kind of approach... or at
least, it couldn't be any harder, because most developers just give up and
don't test their HTML layer at all ;)
Anyway, the only industry standard approach I'm aware of are tools like
those available from Rational, which just add a scriptable testing engine
to Internet Explorer etc. This approach is both non trivial, and
nontrivially expensive, but it's something.
