chevron-thin-right chevron-thin-left brand cancel-circle search youtube-icon google-plus-icon linkedin-icon facebook-icon twitter-icon toolbox download check linkedin phone twitter-old google-plus facebook profile-male chat calendar profile-male
0 votes
I am conscious that even with small classes that adhere to the SRP I am often testing more than a unit. For example method A calls methods B and C in the same class. In this case TypeMock is very useful (when compared to its competitors) because I can mock the internal dependencies (B and C). However in attempting to do this am I trying to take TDD too far?
asked by jagid (640 points)

3 Answers

0 votes
Hi,
What is important in TDD or Unit Tests is to test all scenarios.
Once you know what scenario you are testing you are in the right track.

I actually think the opposite:
If the Simplest Code to write is:
A().B().C();
then just write it, no need to create more methods and refactor the code just to be able to test the scenario.

Of course you should use common sense to decide how to design (or refactor) the production code, but your tests don't need to cloud your design

Many development shops have understood this and they have an easier time embracing unit tests and TDD, while saving considerable time and getting better code coverage.
answered by scott (32k points)
0 votes
Perhaps I didn't explain myself very well. The code is (IMHO) well factored. However some methods are merely aggregations of other methods in the same class e.g.

public void A()
{
  if (B())
  {
    C();
    D();
  }
}


If B() was in another class can mock it using any of the mocking frameworks. It is when B() is in the same class that I am unsure what to do. I know that I can mock B() using TypeMock. My question is whether I should mock B() i.e is intra class mocking is taking TDD too far?
answered by jagid (640 points)
0 votes
I understand.
The answer is that it really depends.
a good way to know is to name the senario.

eg. suppose that B is IsDirty(), then it can make a lot of sense to have a test:
CheckThat_Something_IsDoneWhenIsDirty();
CheckThat_Something_IsNOTDoneWhenIsClean();

and mock the IsDirty();

but on the other hand there will be cases where you should not mock it but actually call it. You will have to use common sense
answered by scott (32k points)
...