Add initial support for jpos injections in tests.

[alcarraz]

This first commit adds support for injecting a log source, and a mocked MUX for jPOS based application JUnit tests.

It is intended to be used by test classpaths in order to avoid boilerplate for logging or mocked versions of jpos or jPOS-EE components such as MUX and DB objects(currently, only MUX is supported). Actually for jPOS-EE specific components a test module by referenced module maybe necessary to avoid unneeded dependencies.

This PR is marked as draft for discussion, specially the classes and annotations names. But if it seems OK, then we can merge it as is

Module for aiding in unit tests

This module provides annotations to inject some mock or frequently needed objects during testing.

For example, it provides an injection for a Log object, and a MUX mock.

Log injection example

In the following example, if the logger does not already exist, a default one, that logs to standard output is created with the given logger name, and assigned to the Log instance.

@ExtendWith(LogSupplierExtension.class)
class LogTest {
    @LogSource (logger="Q2", realm="log-test")
    Log log;

    @Test
    public void testDebug(){
        log.debug("debug called");
    }

MUX mocking injection example

This test class is actually executed in this module's test.

package org.jpos.ee.test;

import org.jpos.iso.ISOException;
import org.jpos.iso.ISOMsg;
import org.jpos.iso.MUX;
import org.jpos.q2.iso.QMUX;
import org.jpos.util.NameRegistrar;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.extension.ExtendWith;

import static org.junit.jupiter.api.Assertions.*;
import static org.mockito.ArgumentMatchers.anyLong;
import static org.mockito.ArgumentMatchers.same;
import static org.mockito.Mockito.when;

@ExtendWith(MUXSupplierExtension.class)
class MUXSupplierExtensionTest {

    private static final String MUX_NAME = "connected-mux";
    @MUXMock(connected = true, name = MUX_NAME)
    MUX connectedMux;

    @MUXMock(connected = false)
    MUX disconnectedMux;

    @Test
    void testConnectedMux() throws NameRegistrar.NotFoundException {
        assertSame(connectedMux, QMUX.getMUX(MUX_NAME));
        assertTrue(connectedMux.isConnected());
    }

    @Test
    void testDisconnectedMux() {
        assertFalse(disconnectedMux.isConnected());
    }

    @Test
    void testMockRequest() throws NameRegistrar.NotFoundException, ISOException {
        ISOMsg request = new ISOMsg("2100");
        ISOMsg response = new ISOMsg("2110");
        when(connectedMux.request(same(request), anyLong())).thenReturn(response);
        MUX mux = QMUX.getMUX(MUX_NAME);
        assertSame(connectedMux, mux);
        assertTrue(mux.isConnected());
        assertSame(response, mux.request(request, 1000L));
    }
}

[fgonzal]

This is really great.

My only (very minor) comment is that maybe we can use a more specific name for the module, like testbed, testtools... something around those lines.

[alcarraz]

This is really great.

My only (very minor) comment is that maybe we can use a more specific name for the module, like testbed, testtools... something around those lines.

Thank you very much, I don't like the name very much either, maybe test-core or core-test but what I really would like is to use is the test fixtures plugin that allows you to define dependencies between module tests.

As it is now we would need a test module per source module, for example, we couldn't put db module tests in this module because it would depend on db module even for modules that don't use jposs-ee-db.

[ar]

We have core, perhaps we can call this one testcore.

[fgonzal]

Thank you very much, I don't like the name very much either, maybe test-core or core-test but what I really would like is to use is the test fixtures plugin that allows you to define dependencies between module tests.

That looks very interesting. I've not played with that feature before.