Take the 2-minute tour ×

I am currently writing Unit Tests to test the connection between a client and a server. At the moment I have the following tests; isConnectionSuccessful, isDisconnectionSuccesful, and isReconnectionSuccesful.

To try and cut down on repetition I have created a getter for a connected client. As the getter tests whether a client is connected I decided to just call it in isConnectionSuccesful as well, however this means a client is returned unnecessarily. For the other tests though, this approach appears to fit perfectly.

Is it ok to go with this approach, and just simply not assign the value from the getter for isConnectionSuccessful or is this a design flaw?

Just to clarify I have the following tests/methods:

//call getConnectedClient

//call getConnectedClient and assign it
//disconnect logic....

//call getConnectionClient and assign it

//instantiate client
//check it is connected
//return client
share|improve this question
I dont see how it is unnecessary, a getter is supposed to return a value. If you have a getter named getClient; it should return the client object. –  Hunter McMillen May 12 '12 at 15:19
Yes, that's what the problem is; it makes sense to use it for the isDisconnectionSuccessful and isReconnectionSuccessful tests as they require the client object, but for the isConnectionSuccessful test although the code is exactly the same and it makes sense to me to just call the method to reduce repetition it results in the client object being returned which isConnectionSuccessful does nothing with. As a result I'm guessing this is a design flaw? –  LDM91 May 12 '12 at 17:54
add comment

1 Answer

up vote 1 down vote accepted

I think you're talking about unit test design here. If so, tests follow somewhat different rules than main source. Your main goals in tests are for the test to be easily understandable and to provide a "safety net" to support changes to the code it's testing. To apply those goals to your question, it might not be immediately apparent to a reader that getConnectedClient does a connection check and thus is the only thing needed in the isConnectionSuccessful test. That might be an argument for writing that test differently. On the other hand, if you feel the test is easier to understand the way it is, then maybe you just need to change the name of getConnectedClient to something like connectClientAndVerifyConnection.

share|improve this answer
Well originally the purpose of the method was to return a client that was verified to be already connected for use in the isDisconnectionSuccessful and isReconnectionSuccessful tests, it was after I had created it that I realised the code I used in the isConnectionSuccessful test matches what's in the getConnectedClient method. Thus, I thought I could reduce repetition in the isConnectionSuccessful test by just calling the getConnectedClient, but it returns the client which the isConnectionSuccessful test has no use for. –  LDM91 May 12 '12 at 17:51
So reducing repetition is one of those things we try hard for in main source, but care less about in tests. In tests, readability can trump repetition. I'd say this is a judgment call for you. The best thing you can probably do is ask someone else who's working with you which way is more understandable. –  Ryan Stewart May 12 '12 at 17:56
Maybe I'm just over thinking it then. A TDD book I have says to refactor to reduce repetition in tests as well as in main source, but I guess it's up to me to make a decision like you said, as you're right it isn't that readable at the moment. –  LDM91 May 12 '12 at 18:36
add comment

Your Answer


