Open cratuki opened 7 years ago
Update: have made progress towards this over last 24 hours. We now have a basic mechanism for writing tests.
:: 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.
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:
This layer proposed here would be valuable:
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.