Extending it

Testing an extension

A handler that is not found does not fail loudly. It behaves as though the document type is unconfigured, and you will look at agreements for an afternoon. Assert that it is found.

The example model ships its tests alongside its handlers, and they are worth copying in shape. There are three things worth asserting, and they take an hour to write.

1. That the handler is found at all

The most valuable test in the set. Ask the module for the handler for your document type and assert that you get an instance of your class back.

This catches the mistakes that are otherwise invisible: an attribute naming an element that was renamed, a class that is not public, a model that is not deployed. All of them look identical from the outside, and all of them look like a setup problem.

2. That it answers correctly

The format, and the business process in both directions. Two assertions per direction, and they are the answers everything else is routed by.

[SysTestMethod]
public void ackTypeRoutesOnBothDirections()
{
    LunoLakeEDIExampleEnvAckHandler handler = new LunoLakeEDIExampleEnvAckHandler();

    this.assertEquals(
        LunoLakeEDIBusinessProcess::EnvelopeAcknowledgement,
        handler.businessProcess(LunoLakeEDIDirection::Outbound));

    this.assertEquals(
        LunoLakeEDIBusinessProcess::EnvelopeAcknowledgement,
        handler.businessProcess(LunoLakeEDIDirection::Inbound));
}

A direction-dependent answer on an acknowledgement is the bug this catches, and it is one that works perfectly for the half you tried by hand.

3. That your acceptance codes are pessimistic

Assert true for the codes you know mean accepted, and assert false for something you have never seen. The second assertion is the one that matters: it proves an unrecognised code is not read as acceptance.

Testing the compare engine

If your type has one, test it against data rather than against a wire file. The engine's job is to produce a verdict from a staged document and your records, and the interesting cases are the yellow ones: a price that differs by a rounding, a quantity in a different unit, an address that nearly matches.

What not to test

Do not write tests that assert your agreements exist, or that a configuration is bound. Those are setup, they differ per environment, and a test that fails because a test company was refreshed teaches nobody anything. Make the wiring hard to get wrong instead: the enqueue seam already does nothing silently when a partner has no agreement, which is the behaviour you want in production and not something to assert against.

Then a round trip

With the tests green, exercise the whole path in a test company: post the source document, read the file the module produced, drop a file in, and watch it land in staging. That proves the parts the unit tests cannot reach, and it takes ten minutes.

Only then involve a partner. Their test environment is a slower place to discover that an attribute names an element that does not exist.