Re: [lmi] wx_test_default_update.cpp

[Greg Chicares]

On 12/20/2014 03:38 PM, Vadim Zeitlin wrote:
> On Wed, 10 Dec 2014 21:17:20 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> I have one concern, though. "MEC avoidance" might not be the
> GC> second item on the first tab. For example, it is not so in
> GC> 'skin_group_carveout.xrc'; we do test distributions that use
> GC> that skin, in which case I suspect the test won't succeed.
> GC> And of course we might change the layout of other skins in
> GC> the future. Is it really onerous to search for this control's
> GC> location across all tabs?
> 
>  I've implemented the function doing just this now and was testing using it
> in this test as well as in the input sequences one, where the same problem
> arose with the "Specified amount" and, as part of this testing, I found
> that this part of the specification comment
> 
> /// Change its "MEC avoidance" option. This particular option is used
> /// because it is available for almost any life insurance product.
> 
> was indeed to be taken literally, i.e. "almost any" doesn't mean "all".
> To be precise, the "MEC Avoidance" radio box appears only in 5 out of 7
> skin files present in the sources, so, as written, the test would fail if
> single premium or variable annuity skins are used.
> 
>  Of course, this might not be a problem at all if distribution-specific
> tests (of which this is one) are only supposed to be run with other skins.
> But if these MEC-avoidance-less skins can be used, what should be done
> about them? Should I follow this advice
> 
> GC> ...so whenever an individual sequence-paste test cannot be run because
> GC> of these reasons, I believe we should skip it silently. (It's not
> GC> actually interesting to report that it was skipped.)
> 
> (from http://lists.nongnu.org/archive/html/lmi/2014-12/msg00064.html)?
> 
>  I am not sure if it makes sense here, especially when we don't really care
> about "MEC Avoidance" at all here, we just want to change any option. So
> maybe the code should just change the selection in the first check/radio
> box we find instead of hunting for a particular option?
> 
>  Or, to make the test more predictable, take one of the options that are
> really present in all skins? Looking at the skins in the sources (I'd paste
> my "one"-line using sed and 7 invocations of "comm -12" to compute the
> intersection here, but I'm afraid this email is too small for it to fit)
> only the following fields occur in all the skins:
> 
>       AgentAddress
>       AgentCity
>       AgentName
>       AgentState
>       AgentZipCode
>       Comments
>       DateOfBirth
>       EffectiveDate
>       External1035ExchangeAmount
>       External1035ExchangeTaxBasis
>       InsuredName
>       Internal1035ExchangeAmount
>       Internal1035ExchangeTaxBasis
>       IssueAge
>       Payment
>       StateOfJurisdiction
>       UseDOB
> 
> So maybe we should just modify "Comments", which seems rather safe, instead?

[Usually I trim quoted context, but trimming any part of it in
this case would make it harder to follow.]

Let's do this:
(1) make sure "UseDOB" is checked (check it if it isn't); then
(2) set "DateOfBirth" to my birthdate, which you have divined.

That's slightly more complicated than we might have hoped, but
we think the benefits are worth the extra cost. We're confident
that "DateOfBirth" will always be present on new skins that may
be developed in the future. It's a field of central importance,
so we feel that using it for this purpose makes the test stronger,
particularly in case we someday make this module more elaborate.
This is the most future-proof solution we were able to come up
with after considerable discussion, and it's very reasonable to
expect that we'll never have to revisit this decision.

>  Speaking of safety, the test specification doesn't say anything about
> preserving the original file, but should the test really modify it? I

Yes, really.

> understand that it's supposed to test that it's created (and I also want to
> test the modification time to ensure that it was really updated, too), but
> maybe it should preserve a copy of the original copy and restore it at the
> end of the test?

Kim and I discussed this, too, at great length, and we conclude
that it is unnecessary to preserve or restore the original.

I originally thought we would need to do that. Suppose we put
together all the files for one distribution, then run this test
suite before burning a CD. Then one of the files that we're
testing is changed as a side effect of the test. Isn't that a
problem?

The answer is: no, it's not a problem. First of all, Kim would
never do that: instead, she burns a CD, installs from it, and
tests the resulting installation--thus guarding against CD
problems. Furthermore, if someone else prepares a distribution
with less care, the worst thing that can happen is that the
default becomes my birthdate, which will do no harm. Moreover,
the default '.ill' file is used only for the first installation
on each machine, so existing users are unaffected.