3

I am new to the concept of TDD and am just starting to get the hang of writing good unit tests for the public interface of my applications.

Currently, I am working on a class library where the public interface is relatively small but there is a large amount of complexity that goes on in classes behind the scenes. This functionality is implemented in internally scoped classes and methods and are therefore not available for unit testing. I do not want to make these classes and methods public because they should not be available to the consuming application but I don't feel like I can adequately test all of the application's functionality without writing more specific test cases.

Can someone explain to me how I might accomplish such testing? Or is something wrong with my approach that I could change to facilitate better testing.

BTW, I am working in a C# .NET environment but I think my question could also apply to Java or any number of other platforms as well.

zaq
  • 2,571
  • 3
  • 31
  • 39

4 Answers4

1

Since you are using dotnet you can make the other classes dll-internal and use the internalsvisibleto attribute in the businessclass to allow the unittest-dll to access them.

Community
  • 1
  • 1
k3b
  • 14,517
  • 7
  • 53
  • 85
0

In Java, you would typically either get around the access checks using something like PowerMock's Whitebox class or use default (package) scope. In other words, no access modifier at all. The unit tests are typically in the same package as the class under test. In .NET, you might be able to get similar functionality with internal scope, but it sounds like you would need your tests and your code under test to be in the same assembly in that case. If that is a problem, maybe you can make your test assembly a friend assembly of the code under test.

John Watts
  • 8,717
  • 1
  • 31
  • 35
0

Most unit test gurus would tell you, that you should only test the public interface. However I do not agree with them, as I often ended up in a similar situation. If you are using C# and a version of Visual Studio, that supports unit testing, then you are lucky. Simply click Test-> New Test... and then select "Unit Test Wizard". Then select any methods, that you would like to test (including private methods). Visual Studio will automatically generate unit tests for you. For private methods it will create shadow classes named like MyClass_Accessor. These classes are exactly the same as your original classes, but their private members are public. These shadow classes also get automatically updated if you change your class.

Eiver
  • 2,594
  • 2
  • 22
  • 36
0

Do not unit test private methods. If it is worth testing, then it is worth to be public or functionality should be in own class. Seems like broken SOLID principles.

Adronius
  • 256
  • 2
  • 6
  • That seems like a naive way of looking at things. The functionality is divided into logical classes that are available to one another internally. It's just that that functionality is not exposed externally. They have single responsibilities, etc but it does not make sense to expose everything that is in it's own class publicly. – zaq Jul 26 '12 at 22:25
  • perhaps another way of looking at this is - if the internal classes are complex enough to warrant being tested, you should consider making them a higher order class (public) or even grouping them logically and moving them to a new assembly. You should test the public interface only, if these test are too complex to cover all internal classes then you have a code smell. It's not a bad thing! TDD helps us move our design forward by identifying these things. – james lewis Jul 27 '12 at 16:32