2

I've read various questions here on the argument like

How do you unit-test a TCP Server? Is it even worth it?

and others more specific questions as

Has anyone successfully mocked the Socket class in .NET?

rhino mocks: how to build a fake socket?

but I anyway feel to post the question.

I need to design an abstract network layer. It should be abstract to decouple consumer code from depending upon a specific implementation and, last but not least, be completely testable with fakes.

I'm ended up that I don't need to mock a Socket class, but rather define am higher level abstraction and mock it.

interface INetworkLayer {
  void OnConnect(Stream netwokStream);
  void OnException(Exception e); // doubts on this  
}

Has anyone done something close to this that can provide observations, comments or explain how may look the right direction?

Community
  • 1
  • 1
jay
  • 1,510
  • 2
  • 11
  • 19

1 Answers1

2

I believe that what you're asking is not about "improving testability" but simply to "test" code sending things over the network.

From my experience, there are only two interesting things to test for things sent over the network:

  1. Is my application sending the right message?
  2. Am I able to send this message over the network?

For example, let's say that your application can send some (applicative-level) message to another server. You can define an interface like this one:



    public interface MessagePort {
        void Send(Message message, ServerName to);
    }

Where Message is the message you want your application to send, and ServerName a class representing an applicative-level way to name the target of the message. For the sake of simplicity, ServerName can be a simple string that can be mapped to the address of the server by configuration, DNS, or whatever. You choose.

You can implement a MockMessagePort, storing the messages into a simple list, to test that your application is indeed sending the right message. (Question 1.)

After that, you can implement the actual sending of the message over the network by using the loopback. You may want to read Uncle Bob's "Craftsman" articles for an example of this.

http://www.objectmentor.com/resources/publishedArticles.html, topic "Craftsman". The test-driven implementation of a TCP server is some episodes away into the series, but you should read it from the start.

An even more interesting abstraction is that of a "Channel" to a message addressee.



    public interface MessageChannel {
        void Send(Message message);
    }

Where the implementation knows about the addressee. Of course, in this case, there is another object providing the channel, from the addressee "ServerName".

If you really want to have an abstract model of the network facilities, well, here is what you can do:

  1. Try to find two different network libraries.
  2. Write the same app twice, using each of the libraries.
  3. Factor the apps. The applicative code should be the same, an the network part should vary. They will be separated by an interface. This is the interface you are looking for.

But honestly, I don't believe that it will bring much to your application.

Laurent LA RIZZA
  • 2,905
  • 1
  • 23
  • 41
  • {+1} for really interesting comments; and what about server side? Something like `Receive(Message message, Client from)`? And another thing, can you provide the link of the reference article you quote at the end of the answer? – jay Feb 17 '13 at 07:38
  • 1
    I edited to add the links, and another useful abstraction. Server side, it really depends on what to do with the message you receive, because you may deliver it to many parts of code. Try to abstract yourself client-side first, and try to make a server-side implementation by yourself first. You'll see what it takes, it will spawn many useful questions. – Laurent LA RIZZA Feb 17 '13 at 10:04
  • {+1} @Laurent LA RIZZA and this definitely answer my question: you confirm me that I need a **higher level abstractions**, rather that cares directly about network _low level_ types. I also appreciated the link of __Craftsman__ articles, a really interesting resource about **design** topics. I want to add this library by J.Gauffin [Griffin.Networking](https://github.com/jgauffin/griffin.networking) with very interesting design decisions and abstractions. – jay Feb 17 '13 at 12:14