I am using STI in my current project and would like to be able to test the base class in isolation. Unfortunately, when I try to create an instance of the base class the fake value being inserted into the type column causes an error.
Invalid single-table inheritance type: fakevalue is not a subclass of
MyTable
Since I could potentially have an unlimited number of subclasses, I would like to be able to test my base class in complete isolation from the subclasses. Since Rails is checking for the subclass this appears to be impossible.
Is there a way?
So after discussing with a coworker, we came to the following solution.
In the spec file, I added an empty dummy class and inherited from my base class. I can then test using this dummy class. Since the dummy class is empty the only logic that gets tested is the base class. I can then add/remove subclasses without fear of breaking the base class tests.
Related
I am facing this problem:
An upstream application defines a class (e.g. box), and a member (say property) with a base class type. I would make a derived class for that member, add new members and methods without updating their application.
Essentially I do box->property = make_shared<myProperty>(). Is there a way to keep the interface of calling the members and methods the same? That is, to access a property using box->property->length or box->property->GetWeight(), rather than dynamic_pointer_cast<myProperty>(box->property)->GetWeight(). The challenge here is they won't update the base property class, and I am not supposed to change box. But we wish to keep the interface the same so our customers won't complain.
Is it possible? If not, how could we do to best keep the main app and my plugin relatively independent while minimize the changes on the customer side? Any suggestions are welcome.
Looks to me like the derived class for that member property violates Liskov's substitution principle.
You mentioned not being able to modify the Box class.
But are you allowed to modify the property base class? I suggest you add your "additional" methods of your derived class to the property base class.
The intent here being that the interface between the base and derived class should be one and the same. So do this only if it makes sense design wise.
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.
In our project - C++, we have the generic module called "ContentCache". From this contentcache, we have derived the customer specific contentcache - for example - Airtel, TataSky. For example, the base contentCache has the method - create the database table, store the basic information. The other types of contentcache which has a relationship like airtel content cache is a type of contentcache. This airtel content cache is customized - overriden a few methods. However, the rest of it are the same. On a few products, we simply use the generic - contentCache. My question is do we need an abstract class - ContentCache - IcontentCache. Also, what is the good way - creating an abstract class or just create a generic base class. What advantage do we get with the IContentCache- i.e. abstract class. I am looking an answer from the design pattern point of view. Also, the programming point of view.
usually you use an abstract class if you define some functionality which can only be used if some additional, unavailable information (or functionality), is needed for that class to work. The unavailable but required information is defined as abstract methods of the class, then derived classes provide that extra information (or functionality).
In your example, if you can usefully have a generic ContentCache then it doesn't need to be abstract. But you might have a design where a ContentCache cannot be instantiated without knowing the name of the specific customer. In this case you might define all of the cache functionality in the abstract base class and have an abstract method which provides the name of the customer. Then in the derived classes you provide the implementation which returns that customer name and the class then has everything it needs to create the cache.
Admittedly this is not a great example as you could just provide the customer name in the constructor of the class, but you mention that in the derived classes you 'override a few methods'. These methods might be candidates for being abstract if they provide functionality which cannot be determined without knowing the customer.
Abstract class is better than just a normal base class. From the design perspective when ever we design a base class , we know that there is going to be inheritance (virtual functions). So we try to collect the common functions in the base class which will mostly be over ride in the derived class. Abstract means hiding the actual implementations from the outside world.Our implementations are our wealth.So base class needs to only work as an interface kind of thing and it should not have any implementation.
Abstract classes are good for you when ever your derived classes are going to ALWAYS use their derived class function definition rathar than using the base class definition.
Normal base classes will be useful , if you are going to use the base class virtual function definition along with the derived class function definition. Normal base class it will be good for small inheritance levels.
In classic inheritance, Derived inherits from Base. With mixins, the (technical) base class is usually called the Mixin. What is the proper term for the (technical) class that inherits from the Mixin?
I want to know this so I can name my template parameters accordingly.
The use of a mixin class is an implementation detail that doesn't impact the result as directly as a base/derived relationship in a typical inheritance tree, so I'm not sure it deserves its own name. The one time I used it most successfully there was already an existing base class that was required (MFC's CDialog), so multiple inheritance was used and my mixin wasn't the first one on the list.
If you really have to pick a name, Derived is probably as good as any.
Probably there is no accepted name for that.
Try:
Final
Concrete
Complete
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.