I am starting TDD both at work and at home (I know I'm late to the party). I already have several tests for public methods for classes. However many of the classes I write have lots of protected functions. When creating a test class, should I have it subclass the class to be tested so I can have coverage on the protected methods?
Thanks,
Jec
In an ideal world, you wouldn't need to test the protected methods directly, instead you would only be testing through the public interface. However, of course the world isn't ideal, and I don't think it's a bad thing to be testing protected methods if there is a good reason to.
I think whether to sub-class or not depends on the nature of the protected methods:
If they are abstract or blank methods designed to be overridden by a sub-class, and you want to test that the methods are being called, then a testing sub-class is a good way to do this, as you can use the sub-class as a way to intercept these method calls and verify how they were called etc. One thing I would say is to be careful that any logic in a testing sub-class is purely for the purpose of verifying method calls, otherwise you could introduce behavior which may impact your tests negatively (for example, you could easily add logic to a testing sub-class which causes a given test to pass based only on the logic in your testing sub-class, and not the logic in the real implementation).
If they are methods in a class designed to expose functionality to sub-classes, then I don't think that you need to sub-class the class under test. Because the methods are protected scope, different classes in the same package can access them, and therefore all you need to do is have your tests in the same package to call these methods to test them (which in my book is generally good practice, the tests should be in the same package but stored in a different directory).
Welcome. It's never too late for the party!
Creating sub-classes to get access to private or protected methods is perhaps the best way. It creates the maximum "surface" for you to construct your tests.
In other situations, I have created sub-classes to allow me to instrument a class under test, to add factory and singleton patterns to a class under test, and to help allow substitutions of mock objects.
You can subclass the class to test its protected interface.
Or you can let a mocking library do the subclassing. Depending on what the protected interface does, that may be preferable.
Specifically, if the base class uses the template method pattern, creating the subclass as a mock is probably better. If the base class just offers helper functions for the derived classes to use, consider putting them into a separate class and making them public.
You should test public interface of your class.
So you don't need to write unit test for private or protected members.
Your private and protected members are called inside public members so when you test your public members all private and protected members will be tested implicitly as well.
Many would argue that you should only test the public methods of a class.
Subclassing would work for protected properties and methods but would not work for private, internal, etc.
Depending on what language you use you can declare the test class and the class that it tests to be "friends" so the test class can see the other class' properties.
Related
Let us assume that you've got a class in C++, for example with an internal state machine that is hard to test. Assume that you have a proper architecture with mocks for all classes used by the class under test. The class under test has some public interface and some non-public internal implementation.
You want to properly unit test this class. In order to make sure that all parts of it work correctly you would like to create some example conditions that you would not allow through the public interface. However, you want to test whether, under these circumstances, the system reacts correctly or not.
One possibility would be to make your member variables protected, so that an inherited class, specifically created for unit testing, is able to extend the public interface to control those variables during testing. You could then, for example, set the system to a certain state, set some internal variables and make sure that e.g. the state transition is according to your requirements.
From a design point of view: Is it justifiable to make non-public members protected in order to be able to get them more testable? What are your opinions? Are there better alternative design decisions?
I had a similar issue. To be honest , I don't see a point why you should not also test the private part of a class.
My solution to this was using the pre-compiler only for the private statement.
#ifndef UNITTEST
private:
#endif // UNITTEST
Of course we could argue now, that I am manipulating the original class itself and I am not any longer testing properly in real conditions , but if you are testing one class and not several within this one unit test I see no issue.
This question about the protected is a bit like the question about making methods virtual for the sake of mocking. You have to decide case by case.
Recently, I was working on the unit test case of legacy code, while writing test cases, I am come up with a problem.
Since I am writing unit test case not integration test. The problem is with private method. In our code a public method is dependent on 5 private method.
For unit test case, I required to give fake implementation of private method, but since method is private, I can't able to-do so.
Because MOQ mocking framework did not support the mocking functionality of private method. and even I can't able to write test case of private method.
Possible approach I was thinking
Move all private method in different class. and make them public and also create an interface of this class. In this way I can able to give fake implementation at run-time because now we have Interface of the class.
But the problem in this approach is I need to make this private method to public just for unit test case. so it is a good practice to make it public.
I do commonly split classes when I start seeing myself writing a lot of private methods. But you have a couple of options:
Fully test the public interface only. You should cover your private methods as a matter of course.
Effective for classes where it makes sense for all the functionality to remain together. That is, the class is already well abstracted and has a Single Responsibility.
Can be a pain if keeping these private methods in the class means more mocking and setup is required for every case.
You can make your private methods internal and specify your test project as a friend assembly. Then they can be unit tested directly.
This can be effective again when it doesn't make sense to split the class.
This has an advantage over testing the public interface when you have a bunch of private methods called by one public method. If you're wanting to test one part of one of the private methods, you don't have to set up everything required by the public method. This also makes things easier to understand and debug.
The solution you already thought of to just split up the class. Sometimes code being difficult to test indicates that there's a class inside trying to break out.
If you can group some or all of your private functionality into a named entity, you might want to pull it apart. Especially if you have other circumstances where you might be able to reuse such a class.
This is also a good option if your original class has a large dependencies list and you can reduce it with this option.
I have an abstract class with some concrete and abstract protected methods, and I have a PHPUnit test for this abstract class.
Then I have classes that extend the abstract class and implement the abstract protected methods.
I'm curious of the smartest way to test that the child classes return what they need to return from the otherwise abstracted protected methods.
I have read a lot that you should not test private/protected methods, but I'm finding this awkward because to get code coverage across the protected method, I must replicate many of the tests from the abstract class test, which involves producing many mock objects and setting their methods to return specific values.
The end result will be a lot of tests that have very tight coupling to other classes. If I changes a class, the tests on for class need to change (totally ok), and then countless mock implementation of that class will need to change also.
At the end of the day, if the abstract class works, then I know my child object will work also, so long as it's implementation of the abstract protected methods returns an expected value.
So I'm wondering if I'm overlooking a pattern.
Duplicating tests across every child class doesn't seem to be better than testing that the child classes correctly implement their interfaces.
You are overlooking a pattern. It would be the Strategy Pattern. The protected methods of the child objects should be refactored into their own object with the protected method as a public method. You would then be able to test that these public methods return the correct thing.
Your tests for the base class would only need to change to have the mock object passed in. If your child classes are only implementing protected methods of the base abstract class. You can remove the abstract from the base class and have the children implement a strategy interface.
This will make your design more flexible. You would be able to easily extend the base class for other reasons and still have all of the previous functionality available to you.
if I have a class with a helper (private member) class within it, like this
class Obj;
class Helper {
friend class Obj;
private:
int m_count;
Helper(){ m_count = 0;}; // Note this is a private constructor
void incrementCount(){
++m_count;
};
};
class Obj {
Helper *m_pHelper;
// note that this is a private getter
int getHelperCount() { return m_pHelper->m_count; };
// the public API starts here
public:
Obj() { m_pHelper = new Helper(); };
void incrementCount(){ m_pHelper->incrementCount(); };
};
So how may I TDD such a system?
auto obj = new Obj();
obj->incrementCount();
// what to assert???
That is my question and the following is just some background.
Response to some answers and comments.
If noone outside the class should be interested, then your tests should not be interested either. – Arne Mertz
If nobody is interested in the value outside the class, why are you – utnapistim
Even if no one outside needs the value, I may still want to know that if it's set correctly, as it is used by other self contained internal method of the class that use that value. Maybe the value is the speed where the controller will use it to update the model. Or maybe it's the position where the view will use it to draw something on the screen. And in fact all other components of Obj would be able to access that variable. It may be a bad design issue, and in this case I would like to know what better alternatives I can have. The design is listed in the background section at the bottom of this post.
define private public - Marson Mao
Love this ingenious abuse of keywords haha. But may not be concluded as the best solution just yet.
You need to "expose" the friendship relation in the header of your class. Thus you have to acknowledge there the existence of a class used to test yours.
If you use the pImpl idiom, you could make the members of the pImpl itself all public, the pImpl itself private and give your unit tests access to the pImpl - CashCow
Does this mean that I should friend the test in my original class? Or add extra "test" methods to it?
I just started TDD very recently. Is it common (or better is it good) to intrude the original class with test class dependency? I don't think I have the appropriate knowledge to judge. Any advice on this?
Miscellaneous: AFAIK TDD is not just writing test, but instead a development process. I have read that I should only write tests to the public interface. But the problem is, like the situation in question, most of the codes etc are contained within private class. How may I use TDD to create these codes?
Background
FYI if you would like to know why I am making a private class:
I am developing a game from cocos2dx. The game engine adopts a Node tree structure for the updates, rendering etc and every game object would inherit from a Node class provided in the engine. Now I want to implement the MVC pattern on a game object. So for each object I basically created a Object class with 3 helper classes corresponding to each of the MVC components named ObjectModel, ObjectView, ObjectController. Theoretically no one should access the MVC classes directly and would only be accessed somehow through the Object class so I make the 3 of them private. The reason of making the MVC components explicitly as classes is because the View and Controller are updating at different rates (more specifically the Controller performs frame dependent updates, while the View do a simple interpolation based on the model data). The Model class is created purely for religious reasons lol.
Thanks in advance.
How to test friend functions of private class?
Thou shalt not!
A class (or module or library or whatever) exposes a public interface for a reason. You have the public interface (which is geared for client use, so it has invariants, preconditions, postconditions, side-effects, whatever - which can and should be tested) and implementation details, that allow you to implement the public interface, easier.
The point of having a private implementation, is that you are allowed to change it as you please, without affecting other code (without affecting even tests). All tests should pass after you change your private implementation, and client (and test) code should (by design) not care at all that you changed the private implementation.
So how may I TDD such a system?
TDD your public interface only. Testing implementation details means you end up coding to an implementation, instead of an interface.
Regarding your comment:
The problem is I don't even have a getter in the public interface. So how can my test check that the value is 0 or 1? And the getter is intentionally made private as no one should be interested in the value outside the class
If nobody is interested in the value outside the class, why are you (i.e. why would you wish to test for it?)
The #define private public trick can have side effects with the way some compiler are mangling function symbols (Visual c++ compiler is including access specifier in its name mangling)
You can also change visibility with the using statement :
struct ObjTest : public Obj
{
using Obj::incrementCount;
}
But like other people said, try to not test private stuff if possible.
I have encounter such problem when I was writing unit test as well.
After some searching I decided the most effective way is to add this in your Test.cpp:
#define private public
NOTE: add this before your desired include file, maybe your Obj.h, for example.
I think this method looks crazy but it's actually reasonable, because this #define only affect your test file, so all other people using your Obj.h is totally fine.
Some reference:
Unit testing of private methods
I vote, as #Marson Mao says, for #define private public.
If you want to control what to make private or public a bit more, you can do this in yourtests.cpp
#define private public
#include "IWantAccessViolationForThis.h"
#undef private
#include "NormalFile.h"
This way you can have a bit more control and try to do this trick in as few places as possible.
Another nice property of this approach is that it is non-intrusive, meaning that you don't need to clutter your real implementation and header files with #ifdefs for testing and not testing modes.
Your friend has full access to the class that it is a friend of. This might be done for many reasons and one of those could well be for unit-testing purpose, i.e. you want to be able to write a unit test that can call private members of the class and check the internal variables show what you would expect them to show, but you do not want that to be part of the public API.
You need to "expose" the friendship relation in the header of your class. Thus you have to acknowledge there the existence of a class used to test yours. No worries, you develop in the real world and classes are tested.
In order to write a unit test you will want to implement that class to provide protected member functions (probably static ones) that call all the relevant private functions or get the private members, and then you write classes that derive from yours. Note that those will not have direct access as friendship is not inherited, thus the static protected members.
If you use the pImpl idiom, you could make the members of the pImpl itself all public, the pImpl itself private and give your unit tests access to the pImpl (through the same model as above). This is now simpler as you only need to create one method for your "tester".
With regards to data members of a class, in recent years I have been known to put all these into a struct, i.e. have them all public, and then for the class to have a private instance of that struct. It can be easier for handling this kind of thing, and also serialisation / factories to your class, where they can create the struct which is all public, then construct your class from it.
I am trying to program according to Behavior Driven Development,
which states that no line of code should be written without writing
failing unit test first.
My questions:
how to use BDD with private methods, and
how can I unit test private methods?
Is there better solution than:
making private methods public first and then making them private
when I write public method that uses those private methods;
or
in C# making all private methods internal and using InternalsVisibleTo
attribute.
When you write code test-first, you write against the public interface. There are no private methods at this point.
Then you write the code to pass the test. If any of that code gets factored into a private method, that's not important -- it should still be there only because it is used by the public interface.
If the code isn't written test first, then -- in .net, anyway -- reflection can be used to directly prod private methods; though this is a technique of last resort.
Private methods are internal implementation details. They should not be tested directly, as they will be tested indirectly via testing your public interface. If for some reason a private method is not covered when your public interface is fully tested, then the private method is not required, and it should be removed.
Generally, it is a bad idea to bind test code to private implementation details. That couples your test to those private details, reducing your freedom to change those details at will, even if they don't affect the publicly facing interface and behavior. That increases the amount of effort required to write and maintain your unit tests, which is a negative thing. You should strive for as much coverage as possible, while only binding to the public interface.
Short answer: You don't test private methods.
If you have programmed well, the code coverage of your tests should be testing private methods implicitly.
If a private method method exists, it's there to be used by a public method. Therefore I'd write a test for the public method.
I write my tests to test the public parts of a class. If the class is well designed then the private parts get tested by default.
If the private method isn't called from a public method, then why does it exist?
In your case I'd do the following
* Write failing test for the public method
* Write public method that calls the private method that doesn't exist yet(test still fails as your class is incomplete
* Write the private method
* Test should now pass
Short answer: You can't test a private method.
Long answer: You can't test a private method, but if you're inclined to test whatever it does consider refactoring your code. There are two trivial approaches:
Test the public method that accesses the private method.
Extract the private code to its own class, i.e. move the implementation so it can become appropriately public.
The first one is simple but has a tendency to let you shoot your own foot as you write more tests and the latter promotes better code and test design.
Contrived answer: Okay, so I lied. You can test a private method with the help of some reflection magic (some TDD tools support testing private methods). In my experience though, it leads to convoluted unit tests. Convoluted unit tests leads to worse code. Worse code leads to anger. Anger leads to hate. Hate leads to suffering…
The direct effect of production code becoming worse is that the class under test tend to become large and handles many things (violation of Single Responsibility Principle) and harder to maintain. This defeats the purpose of TDD, that is to get production code testable, extensible and more importantly: reusable.
If you're writing tests for a class that is deployed, you could investigate everything that calls the private method and write tests accordingly. If you have the chance to rewrite the class then please do refactor it by splitting the class up. If you're lucky then you'll end up with some code reuse that you can utilize.
We can Unit Test static and instance private methods using PrivateType and PrivateObject respectively. The following 2 articles explains these techniques
1. Unit Test Private Static Method in C#.NET
2. Unit Test Private Instance Method in C#.NET
I agree with the point that has been made about not testing private methods per se and that tests should be written against the public API, but there is another option you haven't listed above.
You could make the methods protected then derive from the class under test. You can expose the base protected method with a public method on the derived class, for example,
public class TestableClassToTest : ClassToTest
{
public new void MethodToTest()
{
base.MethodToTest();
}
}
You might be using this Extract and Override pattern already to override virtual properties of the base class for dependency injection, in which case this may be a viable option for you.
Mbunit Reflector helps you with this.
Reflector objectReflection = new Reflector(new ObjectWithprivateMethods());
objectReflection.InvokeMethod(AccessModifier.NonPublic,,"Add",1,6));
A blog post about it.
I've been fighting with it for over 1 month, but found the answer:
var objectOfPrivateMethod = new ObjectOfPrivateMethod(); //yes here is contructor
object[] arguments = { }; // here as Object you provide arguments
var extractedPrivateMethod = typeof(ObjectOfPrivateMethod).GetMethod("Name_Of_Private_Method", BindingFlags.NonPublic|BindingFlags.Static); //if fails returns null. delete flag static if it's not static. Returns your method as an object.
Assert.AreNotEqual(null, extractedPrivateMethod, "Mathod does not exist"); // good to catch if even exists.
object result = extractedPrivateMethod.Invoke(null, arguments); // here as object you'll get return value of your function. change null for object of class where is method, if your method is not static
that's all.
You should only be testing the external API of your classes, i.e. the public methods. If your tests aren't hitting code in the private methods then either you need to write more tests or refactor the class.
The whole point of testing an API, especially one that will be distributed to third parties, is that you can change the internal structure of the class as much as you want, as long as you don't break the external contract of it's public methods.
As you've identified, this is where BDD comes into play over 'traditional' TDD using mock classes, where every method call has to be set-up in advance for the test. I'm not an expert on either of these, hopefully someone else can answer that one better than I can.
If you find yourself wanting to test a private method then there is something complex in it and you are probably right to want to test it, this is a design smell. Exposing the method on the interface just swaps one smell for another worse one.
Time to refactor :)
Usually I factor out the inner complexity into a helper class. However check the method for 'Feature Envy' or 'Inappropriate Intimacy'. There may be a better place for the method to live. With Extension methods in .net now, even base types could be a good candidate.
Good Luck
If you really believe that a private method is complex enough that it deserves unit tests of it's own - it's an indicator that your class is doing too much and you should extract part or all of that private method into a class of its own behind an interface.
Mock the interface when testing the original class. You should now have a public accessor to the new class which was previously the private method.
Sometimes when dealing with old code that was either poorly written or not written using TDD there may be a need to test the private classes. In this case you should use reflection, but where possible update the code to follow closer to the TDD approach.