14 Apr 2014, 15:16

Chris Roberts (1 post)

This book defines a UNIT as the smallest testable piece of an application. I’m still struggling to understand what that means.

For instance, if I’m developing a client that exchanges messages with a server, is the client unto itself the UNIT? Or is the part that transmits the egress messages a UNIT within the client and the message receiver dealing with the ingress messages another UNIT? What about the connection state machine? and so on? Where are the boundaries?

So far in my development I’ve been treating each class as UNIT and mocking and/or stubbing any interactions it has with any other class (in trying to abide by the SRP - is a responsibility equivalent to a behaviour?), regardless of whether those collaborating classes are part of the client or not. I’m starting to question whether this is the right approach…

What do others think? Any advise would be appreciated.

05 Jun 2014, 20:29

Jeff Langr (4 posts)

Hi Chris,

That’s a great question. My definition of “unit” is vague on purpose because it’s fairly arbitrary–if you read more through the book, you get a better sense of what it means when you hit the code. In general, the smaller, the better.

If I’m making a call to a server, I have bits of logic to put together the request, I might have logic to, let’s say, wrap the request to be prepared on whatever transport chosen, I make the request itself, I might have logic to extract the response, I have logic to parse the response and perhaps populate some client objects. I think that’s similar to the divisions you were making. Each of those is a unit that can be independently tested.

The point of the statement, though, is that you should try to find a smaller chunk of behavior if it makes sense as something you could test independently.

To me SRP is a class-level consideration (though you can apply it to member functions as well). A class can have multiple behaviors, still, and each could potentially be considered a unit.

Maybe a better answer is “a unit is something that you can easily write a unit test for.” I find mocking/stubbing not as easy, particularly in C++… so for example if you find you have to use a couple mocks for a single test, it’s likely larger than a unit, and you might possibly need to reconsider the design.

  You must be logged in to comment