LOB-specific context APIs

All of the previous examples of context APIs have been LOB-agnostic. An LOB-agnostic context API is a context API for a business context that functions the same way, regardless of the line of business of the associated policy. An LOB-agnostic context API has a single interface/impl pair.

Some business contexts have testing requirements that vary based on the line of business and based on job. Within these business contexts, there is sometimes a need to share implementation code, and sometimes a need to isolate it. For example:

  • A method to add line level coverages is needed for all policy-related tests, but:
    • A method to add drivers is needed only for personal auto policy tests.
    • A method to add covered workers is needed only for workers' compensation policy tests.
  • A method to quote a job is needed for all job-related tests, but:
    • A method to start a renewal is needed only for renewal tests.
    • A method to apply preemption changes is needed only for policy change tests.

To ensure that there is a way to share code when needed and isolate code when needed, these business contexts conduct their tests using LOB-specific context APIs. In PolicyCenter, there is one LOB-specific context API, the LOB/Job context API. It has a multi-dimensional, multi-level structure. This structure provides a way to share code as needed and isolate code as needed.

There are two dimensions to the LOB/Job API: one for Line of Business and one for Job.

The line of business dimension has a top-level, generic LineContext level and multiple line-specific child levels. Methods that are required for every line (such as addLineLevelCoverage ) are declared at the top level. Methods that are specific to a given line are declared at the child levels. For example:

  • addCoveredEmployees is declared at the workers' compensation level.
  • addDriver is declared at the personal auto level.

The line of business dimension of the Line/Job Context API.

Similarly, the job dimension has a top-level, generic JobContext level and multiple job-specific child levels. Methods that are required for every job (such as quote) are declared at the top level. Methods that are specific to a given job are declared at the child levels. For example:

  • startRenewal is declared at the Renewal level.
  • applyPreemptionChanges is declared at the PolicyChange level.

The job dimension of the Line/Job Context API.

Finally, there is an impl for every line/job combination that requires testing. This impl combines methods from the appropriate line of business level and the appropriate job level. For example, the following diagram depicts an example of PAPolicyChangeContextImpl. This impl combines methods from the line-specific PAContext and the job-specific PolicyChangeImpl.


The Line/Job Context API.

Like Java, Gosu does not support multiple inheritance. To create a Line/JobContextImpl class that inherits information from multiple, non-related parent classes:

  • The job dimension is considered the "primary" dimension. Line/JobContextImpl class extends the appropriate Line/JobContextImplBase class and inherits its methods.
  • The methods from the appropriate <Line>ContextImpl are made available to the Line/JobContextImpl class through the use of a delegate named _lineContextDelegate.

For more information on the LOB-specific context API structure, see The Line/Job Context API.

LOB-specific testing also makes use of tags and a TagInfoProcessor class.

  • Every feature file that has LOB-specific or job-specific scenarios starts with an LOB tag followed by a job tag, such as @personal_auto @policy_change.
  • TagInfoProcessor contains the code that selects the policy type and job type during scenario testing based on the tags in the feature file.