Running real servers for the test suite is tricky when doing curl tests since it involves actual networking. TCP ports are scarce and the TCP stack adds behavior that makes it hard for us to control exactly how data flows to/from the client
A library that offers replacement functions for all the network functions libcurl and the test servers would use could simulate a network, including detailed and crafted network problems, without involving an actual network!
It could offer very detailed and specific control of data delivered between the client and the server and offer exact timing modification.
It also doesn't restrict concurrency so if done correctly, more tests could potentially run in parallel.
The preloading would need to work for both the client and the server since today we use HTTPS most of the time and we want to basically work with our existing TCP+TLS -based test servers.
The preload system would probably create two named pipes somewhere that would provide the TCP+port communication in both directions.
A first test shot could run the HTTP server used by curl (sws) so that it can be told to send/receive data over pipes instead using this preload setup.
The socket_wrapper library from the cwrap project provides basically all this functionality.
LD_PRELOAD=./libsocket_wrapper.so SOCKET_WRAPPER_DIR=uniq-test1 SOCKET_WRAPPER_DEFAULT_IFACE=10 server/sws
LD_PRELOAD=./libsocket_wrapper.so SOCKET_WRAPPER_DIR=uniq-test1 ../src/curl http://127.0.0.10:8990/1
With this system, each test case needs to run its own server instances in a unique directory (possibly named according to the test number) for the named pipes. We also need to do the test case logging in separate directories so that tests failures will be saved and can be properly analyzed after a test run.
When this system works, all tests that have been adopted to preloading can be run in parallel. We can possibly consider limiting the level of parallelism a bit anyway to keep memory use down.