[lmi] Model-view-controller; GUI testing; lmi vs. skeleton trunk; and thanks

[Greg Chicares]

Vaclav--Many thanks for your help with lmi's m-v-c framework:
  http://lists.nongnu.org/archive/html/lmi/2008-12/msg00036.html
  http://lists.nongnu.org/archive/html/lmi/2009-01/msg00001.html
This is a critical part of the system, which has never been reviewed
before. It may benefit greatly from further expert review.

I won't try here to explain the m-v-c code's purpose: that's already
documented inline (mainly in 'mvc_controller.hpp'). But I would like
to explain why there are two cvs trunks here:
  http://cvs.savannah.gnu.org/viewvc/lmi/
The 'lmi' trunk is of course our production system, so the question
is what the 'skeleton' trunk is for.

The 'skeleton' trunk is the m-v-c stuff along with all of its (many)
dependencies. It's "library" code: a GUI layer written on top of wx
that could serve as an application skeleton for a program other than
lmi that has similar GUI requirements but is in a different domain.
As such, it embodies no insurance knowledge. It contains nothing that
you shouldn't be able to understand better than I do. A domain expert
working on the insurance parts of lmi, conversely, shouldn't need a
deep understanding of anything that lmi shares with the 'skeleton'
trunk...as long as it all "just works".

And 'skeleton' is almost a subset of 'lmi'. Here are total file sizes
in kibibytes as of about 2009-01-01:

  5541 KiB lmi
  1234 KiB skeleton
   984 KiB common [though not all file-pairs are identical: see below]
  4035 KiB lmi only
   347 KiB skeleton only

206 of the 347 KiB in 'skeleton' only are in these incidental files:
  ChangeLog* *.html *.png *.txt *.xpm
so no more than (347-206)/1234 = 11% is code unique to 'skeleton'.

So the 'skeleton' trunk is a library, in several essential ways:
 - a separate body of code,
 - elaborately tested [see 'mvc_test.cpp'],
 - with extra attention paid to "quality".
Counting known defects marked inline gives a simple proxy for quality:

  skeleton       lmi
       156       456   source files
     29032    133985   source lines
        31       878   marked defects
     ~ 1.1     ~ 6.6   marked defects per KLOC

where each '??' marker flags 'technical debt'--in this
  
http://blogs.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx
taxonomy, the "intentionally incurred" type.

Still, 'lmi' doesn't quite use 'skeleton' as a library, especially in
that about half the files common to both trunks differ somewhat. Some
differences are adventitious, and their sporadic but routine removal
accounts for perhaps ten percent of 'ChangeLog' entries in 'skeleton'.
Of the rest, a few are intrinsic and irremovable, but most represent
technical debt stemming from "expedient" changes in 'lmi'.

Ultimately, I'd like to rework the "expedients" and use 'skeleton' as
a proper library. Until I can, I accept the chore of maintaining it as
the price of keeping those "expedients" distinct. And it has another
virtue: its automated GUI tests, in 'mvc_test.cpp'. That's a valuable
layer of extra protection whenever we upgrade wx, and it can even help
us pay back the wx community--if I had kept 'skeleton' up to date and
run its tests with wx-2.8.8, then we might have found this problem:
  http://lists.nongnu.org/archive/html/lmi/2008-08/msg00026.html
in a wx-2.8.8 release candidate.

Years ago, I considered copying that GUI-test facility into 'lmi'.
That was a bad idea for two reasons. First, the automated GUI test is
intrusive (perhaps it can't be otherwise), which makes it incompatible
with stronger encapsulation in the production system. Second, it's not
worth resolving that incompatibility. If 'skeleton' has comprehensive
tests for every way 'lmi' uses spincontrols (e.g.), then it would be
senseless to add a test in 'lmi' for each spincontrol. And if such
library tests aren't yet comprehensive, then they should be augmented
in the 'skeleton' library.

Soon I plan to use 'skeleton' as a testbed to add this feature:
  http://savannah.nongnu.org/support/?104481
by extending the m-v-c framework. That's yet another advantage of this
secondary trunk: I can change it without any possibility of perturbing
the production system, and move well-tested features into production
at leisure.

I hope I've explained these non-obvious matters well enough that you
can see how very glad I am to have any review comments you'd like to
offer on the m-v-c stuff. It's present in both trunks, and right now
you probably don't want to spend a lot of time on 'skeleton' because
many of your changes in 'lmi' haven't percolated over there yet. But
it might be useful if you could at least build 'skeleton', even if
only in order to run its './skeleton --unit_test' GUI tests.