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.
Related
This might be a noob question however, I am not entirely sure on the procedures to writing unit tests for an abstract class in Salesforce. The class itself has 3 public methods as well as two abstract unimplemented methods. I unfortunately haven't found much help on the topic.
I know abstract classes cannot be constructed which means I can't create an instance of it to test on. Greatly appreciate any inputs.
What ultimately worked for me was, I used a class that was already extending the abstract class to call the methods I needed to test. I didn't need a mock object or to create a whole new sub-class to test.
You could create a test subclass which would implement those abstract methods with dummy implementation.
That way, you can instantiate this test class in your test: calling its non-abstract methods will run the production code.
Alternatively, you could look into mocking frameworks: they might even remove the need to subclass the class yourself.
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.
How do I mock non-overridden non virtual/virtual methods in a base class and test just the derived class's methods?
The case here is:
I have a base class X which has methods that connect to an external server and do a couple of other things.
I have a class Y derived from X. I have implemented two methods in Y. I want to just unit test them. I am worried only about these two methods and I don't want the base class implementation to be called to connect to the server etc( I want to mock those methods out , but i don't want to override those methods in my derived class Y and do nothing in them, since it is production code).
Any thoughts /ideas on how can I unit test my those methods in isolation?
P.S: I am using C++/GTest for development and unit testing.
One option is to create a Mock_base class and the class Derived inheriting from it in the test directory. Now mock out any implementations in the actual Base that you are not interested in with functions that do nothing. Example the Mock_base::Connect() may return SUCCESS return code. This way you can unit test the Derived:funcs() without modifying the source code.
You're really lucky you are having a hard time doing this!
Functionality is most of the time not intended to be reused through inheritance, and this is one good reason for that: your base class implements some interface that you want to mock out for a client (i.e. Y). Possibly, this functionality may later be implemented by some other class, too, and Y should be able to use that new, possibly better, implementation.
Y has/uses an X, but Y is not an X.
If your Y class needs to use X's functionality (connect to server etc...), it should aggregate it, not inherit from it.
You'll notice that the aggregation scheme allows for mocking just like that.
What is the best way to unit test subclasses? Let's assume there's a base class for which I've already written tests and there are some number of subclasses that override some of the parent's behavior in public and/or protected methods.
Should the test class for my subclasses extend (and override test methods where appropriate) the test class for my base class so that all of the base class tests are applied? Otherwise, I would expect to have repeated test code.
According to the Liskov substitution principle, instances of the subclasses, should exhibit the same properties as the base class, and, thus, pass (all ?) the same unit tests.
I would run [perhaps not all, all that are relevant] the base class tests for each subclass. This can be achieved with a test helper.
Yes, subclassing the test class could be a good way to avoid duplication in the unit tests. Have a look at the Testcase superclass pattern.
It is difficult to see without an example, but I would test the base class in one set of tests, and then create new tests for the subclasses and just test the behaviour that differs.
I have question that bothers me for few days.
Abstract class is a special type of class that we cannot instantiate, right?. (Which is denoted/specified by giving a "= 0" to at least one method declaration, which looks like an afterthought).
What are the extra benefits that the abstract class mechanism brings to C++, that a 'normal' base class cannot achieve?
According to the wikibooks section on abstract classes:
It's a way of forcing a contract between the class designer and the users of that class. If we wish to create a concrete class (a class that can be instantiated) from an abstract class we must declare and define a matching member function for each abstract member function of the base class.
As mentioned, it's a way of defining an interface to which derived classes must adhere. Their example of the Vehicle abstract class is very apropos: you'd never have just a Vehicle in real life, you'd have a Ford Explorer or a Toyota Prius, but those both conform to (for the sake of argument) a base set of functionality that being a Vehicle might define. But, you can't just go to the Vehicle dealership and drive a Vehicle off the lot. Thus, you'd never want to be able to construct and use a base Vehicle object where you'd really want a specialized, derived object.
This offers the best way in C++ to define an interface without any default implementation.
C++ does not have C#'s interface concept.
It's the equivalent of what Java turned into "interfaces". Basically, it implies that the class itself is not usable - you need to override all pure methods.
An example is MFC's CView class which has a pure OnDraw method - the basic CView doesn't do anything and is as such useless. You have to override OnDraw.
(Btw - it is still possible to provide an implementation for a pure method, and subclassed implementations can fall back to it, but they still have to provide their own override.)
They are used as a base class in a class hierarchy design.
Abstract classes are used to define a clean interface for all derived classes.
At design stage, abstract classes define an interface, per specification and derived classes implement the desired functionality accordingly.
Also using abstract classes instead of "normal" classes helps separating the implementation details from the interface.
A concrete class implements an interface, but the abstract class defines it. You could use a concrete class as a base class in your design but abstract classes are not meant to be used directly in code and can not be instantiated. They serve as prototype.
By using the "normal" class as you say, you have to define an implementation for all methods.
Don't think of it at the class level.
Look at the method, and think of what it should do in the default case:
virtual std::string getName() const = 0;
What would be a right implementation for this method ? There is none than I can think of.
By marking it "pure virtual", you ensure that if the user ever get an instance of a class derived from your interface, then this method will have a sensible behavior.
The only other way to do this would be a throw NotImplemented("getName"); body, but then you'd discover the issue at runtime, not at compile-time, which is not as nice :)