eng: embed eng in a unit test framework

[cratuki]

Major work to set Eng up for the future by creating a comprehensive unit test settlement for it. We will create two kinds of unit tests here:

• A test layer that faces OS libraries (check platform assumptions)
• A test layer that faces eng to supply

This layer proposed here would be valuable:

• would give far better coverage of existing functionality
• we will want to add support for true multicast and unix domain sockets.
• would aid any future work towards replacing the python stack with low-garbage or stack-bypass arrangements.
• will give tools for testing behaviour of new third-party net APIs. For example, we could test releases of openonload.

Approach:

1) Identify the intent of each calls we make into the API when we access OS-supplied socket functionality. For example: select, create_socket, recv, bind, accept.

2) Create a suite of standalone tests against the python API for each of the functions we currently use. Get this into CI. (Useful: if something changes in core python, we will be first to know about it. If we want to evaluate pypy, we now have a mechanism for that.)

3) Create a new package in solent in which we will house our new API. solent.netapi

4) Move all the current calls to socket and select to instead access exposed mechanisms in solent.netapi.

5) Continuing this work, now refactor away from OO approaches such as "socket.recv" to purpose-built functions. Hereafter, these are referred to as NFs (Network Functions).

6) Refactor all the names to a consistent format. For example, netapi_recv.

7) Create unit tests for each of the NFs to match each usage we currently use. Hereafter, these are UTs.

8) Using the UTs, build corresponding fake versions of each of the network functions in a separate module. Hereafter, FakeSocket

9) Build on the UTs to create broader unit test functionality.

10) Tie all of this into a CI pipeline.

[cratuki]

Update: have made progress towards this over last 24 hours. We now have a basic mechanism for writing tests.

[cratuki]

:: Thought.

In issue #107 we are going to divide the codebase into "foundation" and "extensions". Everything that gets loaded as an extension is meant to return a form. I am hazy, but this may give us a better foundation for unit-testing that we have at the moment.

Consider this hypothetical,

• We have form_eloop_provider.

• There is a default implementation of this, select_form_eloop_provider.

• We implement an extension, epoll_form_eloop_provider.

It should now be possible to replace the real POSIX calls that these call with a fake library that simulates their behaviour.

:: Another thought

We may be able to run integration tests if we had docker in our build pipeline.