Quote:On many systems select() is implemented internally as poll anyways.

Which makes select() even less efficient, because it needs to build and tear down the list of file descriptors for each call to the kernel. For large numbers of file descriptors (dense select() bit arrays) this gets really expensive.

Quote:testing

There are two layers of testing (at least): Unit testing, and functional testing.

With unit testing, you write code inside your .cpp files. That code runs when in test mode, and calls an individual function of an individual object instance, to verify that given known inputs, the function returns a known output. This is done one function at a time, with as much insulation as possible from the rest of the system. If the function called depends on a file system, a network, a timer etc, then those services are generally mocked (replaced with narrow shims that just return known dummy data).

With functional testing, you generally build some mode into your client such that it can be scripted from the command line, or load and run a script when invoked. That script performs user-level operations (connect to server at address X, send login Y/Z, issue request W, ...). It then verifies that the right thing happens. Generally, you want the ability for a server to run in a "sandbox" where it is self-contained, and you can set up a known good initial state. If you generally use MySQL for database operations, the sandbox might use a different database name, or may even use SQLite instead, for example. For persistent files, the sandbox may put them under /tmp/sandbox instead of whatever the persistent location usually is.

Both kinds of testing are important. Personally, I find it hard to break down certain systems all the way down to unit test level, and some of my unit tests will have a functional flavor -- like, to test the sockets implementation, I may create two sockets, listen on one, connect on the other, and send "hello, world!" and then verify that I can receive that. That exercises more than just a single function on the sockets class, but it can still be run at unit test time because it doesn't need any other information or support (outside of the underlying BSD sockets implementation, natch :-)

Similarly, at other places where your classes interact with the kernel, you may need to make "functional" style unit tests. For example, the function that tests your wrapper for epoll() will likely need to use multiple objects. A simple test for that might look something like:

create three sockets; one listening, two idle
run the epoll with a timeout
verify that you get nothing back
connect one of the idle sockets
run the epoll with a timeout, until timeout expires (fail) or you get "writable" from the connecting, and "readable" from the listening/accepting socket
create a fourth socket based on the "accepting" socket incoming connection
run the epoll with a timeout
verify that you do not get "readable" from any of the sockets
...

Because the OS doesn't support dependency injection (without really tricky and expensive work), you will end up having to use functional testing for the OS interface code. There's really no good way around that.
Anything that sits on top of your OS abstraction, though, should be unit testable at the single-function level, if you design it with that as a goal.