Re: [lmi] Toward a 7702A testing strategy

[Greg Chicares]

On 2006-01-06 14:13Z, Greg Chicares wrote:
> 
> A real-world unit test [...] isolates the inputs and outputs we
> care about. What it isolates is small enough to calculate by hand.

Class 'mec_input' embodies the necessary inputs fairly well, though
of course we may refine it. Now let's consider what outputs would be
helpful so that we can establish a suite of '.mec' unit tests (which
can replace 'irc7702a_test.cpp'). Recording only the most important
results--MEC status, 7PP, LDB, and perhaps DCV--is not enough:
 - they might all be correct for a particular test case, even though
   there's an error in some intermediate step--so that a defect that
   might have been detected escapes notice; and
 - if they seem to be incorrect, then the reason remains obscure--so
   that an excessive amount of spelunking is required.

This matrix seems to capture most 7702A calculation details [0] for
a group of transactions applied on the same day (which is exactly
what a '.mec' file tests):

            issue,
          inforce,
           or 1035  incr  decr  nec_prem  MC unnec_prem
  bft          +      +     +       -      -      -        3
  LDB          -      -     +       -      +      -        2
  amts_pd      -      -     -       +      -      +        2
  MC           -      +     -       -      -      +        2
  DCV          +      -     -       +      +      +        4
  7PP          +      -     +       -      +      -        3
  MEC          +      -     +       +      +      +        5
                                                          21 / 42

Columns are events that trigger a calculation. Rows are values that
may need to be recalculated due to various triggers. Intersections
are marked '+' where a value might change, and '-' otherwise; at the
right is a total of '+' signs. Calculations generally flow from left
to right, and within a column from top to bottom.

I'm inclined to include all of that matrix's forty-two data in an
output file for testing, without even bothering to compress out the
half that AFAICT cannot bear any actual information. Symmetry and
clarity seem more important than saving a few bytes.

The output file should also record certain scalar values that aren't
affected in different ways by different triggers--including these
values that are looked up or deduced directly from input:
  policy year
  contract year
  7PP rate
  NSP rate
  target premium
  target premium-load rate
  excess premium-load rate
as well as these intermediate calculated values:
  net 1035 amount
  NSP (dollar amount)
  gross and net maximum necessary premium
  cumulative 7PP and cumulative amounts paid
and these results that an admin or illustration system would either
use or store for subsequent use:
  maximum non-MEC premium
  last MC date
  cash value as of contract duration zero (for later decreases)

I'll probably use xml for the output file.

---------

[0] "This matrix seems to capture most 7702A calculation details"

Here are some notes on its rows and columns.

The first column represents the initial state determined by input
parameters on the as-of date. It's new business if that date equals
the effective date; otherwise, it's inforce. A 1035 exchange is
permitted only as of the issue date.

The increase and decrease columns might have been combined. I've
kept them separate because their effects are very different.

Amounts paid are separated into necessary and unnecessary portions
because material changes are recognized after the necessary portion
has been applied.

The amounts-paid row represents premiums less any nontaxable
distributions. The benefits row represents either death benefit or
specified amount, depending on the insurer's 7702A interpretation.

Material change appears both as a column and as a row. It's a column
because it triggers changes in other values. It's a row because its
value is an important part of the state of the contract. The column
shows the effects of processing a material change; the row indicates
that it may or will be necessary to process a material change.

A material change is processed before any unnecessary premium is
applied. Payment of unnecessary premium is one possible trigger for
recognizing a material change. The apparent circularity is resolved
by observing that the presence of pending unnecessary premium can be
ascertained before its application.