NFD

Junxiao Shi wrote:

• send
• receive normal
• receive malformed

The send and receive paths of TcpTransport and UnixStreamTransport are completely identical (they're implemented in StreamTransport), so there's no point in duplicating these tests for both transports. As a minimum, the checks should be abstracted into a common implementation.

• check counters after send and receive

Unless the subclass extends the counters with transport-specific ones (not the case here), incrementing counters is the responsibility of the base class Transport. Testing all subclasses makes no sense.

• close from transport
• close from peer socket

Same comment as send/receive.

The send and receive paths of TcpTransport and UnixStreamTransport are completely identical (they're implemented in StreamTransport), so there's no point in duplicating these tests for both transports. As a minimum, the checks should be abstracted into a common implementation.

It's necessary to test both TcpTransport and UnixStreamTransport, because the usage of a StreamTransport class template is an implementation choice.

Yes, they can be tested with a test suite template.

Unless the subclass extends the counters with transport-specific ones (not the case here), incrementing counters is the responsibility of the base class Transport. Testing all subclasses makes no sense.

It's necessary to test all transports, because having the Transport base class incrementing counters is an implementation choice.

Junxiao Shi wrote:

It's necessary to test all transports, because having the Transport base class incrementing counters is an implementation choice.

This is not how (our) unit testing works. Are you suggesting we should do black-box testing everywhere? Then also the fact that a Face is a Transport + a LinkService, and many other assumptions, are implementation choices.