Subclass To Test Anti Pattern

SubclassToTest is an AntiPattern:

AntiPattern Name: SubclassToTest

Type: Design

Problem: Need to fake, mock or stub methods in a ClassUnderTest, and/or classes it uses.

Context: automated (xUnit) testing of one or more classes in a system

Forces: [forces]

Supposed Solution: Resulting Context: Replacement positive patterns: Design Rationale: [rationale]

Related AntiPatterns:

Applicable Positive Patterns:

AntiPatternCategory: DevelopmentAntiPattern / lack of ArchitectureAntiPattern

Also Known As: [other names]


Examples in the Literature:
Examples in Practice:

[Discussion]

"Discussion"?? Here's a quarter, sonny. Go get yourself a language with DynamicTyping!

Doesn't seem like DynamicTyping would avoid the problem; rather, it might make it worse, by making it more difficult to see the tests that are overriding ClassUnderTest methods.


In my opinion, SubclassToTest is a bad idea. First, I think having a UnitTest that needs to muck around in the implementation details of a class points to an encapsulation problem or maybe some problem with the abstraction. Second, SubclassToTest inhibits one's ability to refactor. However, if I restrict UnitTesting to public features, I am free to refactor the implementation and view the class from the using perspective.

Therefore, I always write UnitTests without violating the interface of the ClassUnderTest. After all, if you can't reach some behavior from the PublicInterface, why is it even in the class?

As a result of doing this, I get to see my class from the perspective of class user rather than class provider. If I end up feeling the desire to violate the abstraction, so will the real user.

Therefore, when you feel the desire to go beyond you public features, instead take the opportunity to revisit the design of your class interface.

FWIW, I do have a parallel package hierarchy (as described above) so my tests can access package-data without having to be shipped with the production code. This way, you don't pollute the package namespace. I use JBuilder, so I just change my source path from "project\src" to "project\src;project\test". All my TestCases go into the "project\test" directory but look as if they are all one project to the IDE. However, I rarely, if ever have actually used this feature to access package visible attributes -- it's more just a convenient way to organize my test cases. { This is also the way Maven organizes the sources by default. }

[Additional comment moved to AbstractTest.]

-- RobertDiFalco


"The SubclassToTest AntiPattern should be banned." -- JeffGrigg


See also: SubclassToTestDiscussion
CategoryAntiPattern

EditText of this page (last edited January 27, 2011) or FindPage with title or text search