If I have a type with a big-old (lots of params) constructor, is it a valid approach to implement a protected parameterless constructor simply for the purposes of creating a derived "Fake" type to use for stubbing in unit tests?
The alternative is to extract an interface, but this is not always desireable in a codebase you do not have full control over...
It's not ideal, but it is valid.
To quote a couple of people who know more about this than me, in The Art of Unit Testing, Roy Osherove talks about unit tests being like a user of the code, and as such providing access specifically for them is not necessarily a bad thing.
And in Working Effectively with Legacy Code, Michael Feathers discusses several such techniques, pointing out that making things protected for testing can be better than making them public, although it's not necessarily the best way to do things. (In fact I'd recommend you read that book if you are working with legacy code, as it sounds like you are).
I think it depends what sort of code it is - if it's a public API where people are likely to take protected access to mean it's designed to be overridden, it's probably a bad idea, but on a typical business app where it's pretty obviously not meant to be overridden, I don't think it's a problem. I certainly do it sometimes in this situation.
Since you essentially have to treat protected the same as public, the answer would be no from a strictly object-oriented point of view.
You could add a private parameterless constructor though and invoke it through reflection, if that's not too much hassle.
Could you not create a class which extends the class you want to test? That lets you use your own constructor without having to create an interface.
Modifying your code or API to facilitate unit testing is generally undesirable (see the "Should I unit test private methods" debate), so actually using a new class rather than modifying your existing one might be the way forward.
There is the argument that non-sealed types should always declare a protected parameterless constructor (where your others have parameters).
This allows flexibility for subclasses to instantiate the class in their own way, not forced to provide parameters to the base constructor.
Mocking frameworks are just such an example of a subclass that wants the freedom to be able to instantiate the class in its own way; the mock object doesn't care for setting property defaults or dependencies since it will mock the return values anyway.
One day, your own classes or library customers may have wildly different ideas about setting up the class, and you don't want a type that you cannot evolve months down the line because you're forced to push something that's no longer necessary into the base ctor.
There are rare cases when you absolutely need to force some initialization value, but it is rare - note that structs should not have parameterless ctors.
Related
I am very sorry if this question seems stupid, i am a newbie to TCL and TCLtest, I am trying to perform unit test on a few TCLOO programs, and i am having difficulties testing the private methods ( the methods called using keyword 'my' ). Guidance needed
Leaving aside the question of whether you should test private methods, you can get at the methods by one of these schemes:
Use [info object namespace $inst]::my $methodname to call it, which takes advantage of the fact that you can use introspection to find out the real name of my (and that's guaranteed to work; it's needed for when you're doing callbacks with commands like vwait, trace, and Tk's bind).
Use oo::objdefine $inst export $methodname to make the method public for the particular instance. At that point, you can just do $inst $methodname as normal.
Consequence: You should not use a TclOO object's private methods for things that have to be protected heavily (by contrast with, say, a private field in a Java object). The correct level for handling such shrouding of information is either to put it in a master interpreter (with the untrusted code evaluating in a safe slave) or to keep the protected information at the underlying implementation (i.e., C) level. The best option of those two depends on the details of your program; it's usually pretty obvious which is the right choice (you don't write C just for this if you're otherwise just writing Tcl code).
This might look like OT, but bear with me.
Are you sure you have to test private methods? That sounds like testing the implementantion, and thats something you shouldnt do. You should be testing the behavior of your class, and that is tested through its public methods.
If you have a complicated chunk of code in one of the private methods, and you feel it needs to be tested spearately, consider refactoring the code into two separate classes. Make the method that needs testing public in one of the two classes.
That way you avoid having a "god class" that does everything and you get to test what you wanted to test. You might want to read more about Single Responsibility Principle.
If you need specific book titles on refactoring, id recommend "Clean Code" by Robert C. Martin. I love that book!
If I have a class that inherits from another, and only this class has to use a certain variable, which is better practice? To have said variable be 'protected' in the base class, or have it private and give it a protected getter?
I've heard conflicting things. My teachers told me to always use getters, while other people have told me that using getters at any level reveals bad program design. What's the real answer? I feel like both are illogical extremes.
Also, if getters and setters are bad program design, why is this?
Are there any resources that will teach me more about how to structure my code?
Do you need (or anticipate you will need in the future) to do anything else other than just reading a value? For example: assertions, locking or making the read polymorphic?
If no, use the field.
If yes, use the getter.
Whether you use protected or not is completely orthogonal to that.
BTW, managed languages such as C# and Java often require the presence of getters, where "logically" just the ordinary fields would suffice, because their UI design (and other) tools were implemented to use reflection that way. So the practice of excessively using getters seems to have "rubbed off" the C++, despite the lack of reflection or such tools in C++.
protected is closer to public than private. People can create a derived class, access and change the protected members and use their derived instance as an instance of the base class. You can make your decision based on that. If you want a data member to be read-only for the outside world, you need a getter and there is no way around that. A protected getter (and maybe setter) can also work.
Another thing to note is that setters can act as a gateway to your data. They can be used to validate ranges and throw exceptions when needed. Take this into consideration as well.
Also, since you said that it is for use by a certain derived class, you might want to make that class friend. This may or may not be a good idea, you should carefully evaluate pros and cons.
I don't think that getters and setters are generally bad design. I'm sure they can be abused, as almost any idiom or pattern. Generalizing is never a good idea.(1)
(1) Yeah.
Your protected and public interface (classes, members, fields) are things that you need to keep stable. Every time you change your protected and public interface, you have the potential to break any code that depends on it.
This might be one line of your own code that you break. It might be hundreds of classes in your own codebase. If you shipped your code somewhat publicly, then you might break thousands of lines of code from hundreds of programmers you've never heard of and will never meet.
Sometimes this break is necessary and good. Sometimes it could have been avoided with a little foresight. Getting into the habit of understanding and considering your reasons for change is the core to good design.
if getters and setters are bad program design, why is this?
Getters and Setters give you only a small amount of encapsulation. You still aren't hiding much from users. They still know there's a field of that type in your code (or at least know you're pretending that that there is), and they depend on it being there. If you changed the implementation of your class in such a way that made that field unnecessary, you couldn't remove the getter/setter unless you were willing to break all dependent code. If you tried to avoid the break, you'd have to make those accessors still work and make logical sense, which might be difficult.
Sometimes exposing a field (or a Getter/Setter) makes sense, even in high level code. If that field is important to access, and would never have a good reason to change name or type (from the view of a programmer using your code), then it might be fine and good and best to expose it in some way.
Sometimes wrapping fields in a Getter/Setter makes sense. If you have Getters/Setters, it can be easier to add logging, bounds checking, thread locks/semaphores, and debugger breakpoints. It is also easier in C++ to define an abstract interface that requires a Getter/Setter to be present than it is to define an interface that requires a field to be present.
Sometimes directly exposing a field, and not using getters/setters makes sense. Sometimes "classes" made entirely of fields makes sense (consider using a struct instead). This is going to be most common in very low level code (such as code that pulls data out of a file), or inside the implementation of another class (such as in the implementation of an algorithm). Often you'll hide these classes inside other classes, so users of your code never see them.
My teachers told me to always use getters, while other people have told me that using getters at any level reveals bad program design. What's the real answer? I feel like both are illogical extremes.
Blanket statements often have truth to them, but truth is seldom binary.
Get in the habit of asking "why?". Get in the habit of judging truth for yourself, and judging situations within their own context. Sometimes what is "always best" is not actually best, or even desirable at all, in a specific situation.
In most cases, getters and setters do reveal bad desing. But there is no general rule. The main reason to use getters and setters should be for debugging, so when you're accessing some base class member from a derived class, you have a point you can set a breakpoint at to intercept changes to that member.
So, you should adapt. If you plan on having 2-3 levels of inheritance, it's better to go with protected members, since there aren't that many places the member can change. If more, protected setters/getters might be a better option - you don't want to set breakpoints in every class that can possibly modify a member of the base class.
If the member in the Base class is not required to be accessed outside the derived class then you make them protected in the base class. That is the purpose of protected access specifier.
Getter and setter methods are an explicit way of saying that this member variable is available for use and usually they should be used to expose the member to external entities. They make the intent clear, but since your variables only need to be accessed in the derived class, the protected access specifier already expresses the intent clearly.
What are classes. Collections of data or collections of behaviors?
Of course they're both. But let's contrast how fields and accessor methods (getters and setters) enable you to work with data and behaviors.
Fields
Are data
You can't alter their behavior without altering dependent classes (unless they're pointers to abstract base classes)
They can be directly accessed with operators, so can be used inline in expressions.
You can't get as clever with their noun-based names. They usually won't be tied to beahvior.
Accessor methods
Are behaviors
You can change them without having to alter dependent classes (assuming you've kept the same contract)
You cannot access them directly with operators, so can't be used directly in as many expressions (without some work).
You can do Method Chaining with them.
You can get as clever as you want with their verb-based names (Get, Create, Find, etc). They define a behavior.
Tangent: Method chaining is neat, because it lets you create something called a "Fluent Interface".
Encapsulation
Whatever you do, you should remember your OO principles. Don't violate your encapsulation.
If you write a class that is suppose to encapsulate its whole behavior, yet exposes a field, you've broken your encapsulation. If you've written a class that stores data, and has convenient assignment/data-generation patterns that happen to map well to methods on that class, then you haven't broken your encapsulation.
Which case is true for your class depends on the level of abstraction the class is operating at.
When to use each
They both make sense to use in certain contexts.
It makes sense at lower levels of code to work more closely and intimately with data. In these cases you should use the most performant and most data-tied syntax you can. Use fields.
It makes sense at higher levels of code to work more closely and intimately with behaviors. In these cases you should use the most flexible and most behavior-tied syntax you can. Use accessors. Or, often, don't use accessors. Use interfaces, classes, and non-accessor methods instead.
When in doubt, I opt for flexibility over performance. It is hard to predict performance bottlenecks in whole programs by examining things at this particular level of detail. We're really bad at it, and that is why profilers exist. It is easier to make an accessor into a field than vice-versa. If you're careful and lucky, you might already have your accessors inlined, which would then make it a moot point.
Since a few years, common sense seems to dictate that it's better to program against interfaces rather than against implementations. For high-level code this indeed seems logical, e.g. if I have a complex solver in my application, it seems better to have something like this:
ISolver *solver = solverFactory.getSolver();
solver->solve(inputdata);
Rather than
Solver solver;
solver.solve(inputdata);
In the first code it is also easier to mock the solver, and thus, to unit test.
But my question is: at which level doesn't it make sense anymore to use interface. E.g. if I have a ComplexNumber class (or String class, or whatever) in my application, then writing this:
IComplexNumber *complexNumber = complexNumberFactory.create(1,2); // 1+2i
Seems much more complex (especially regarding performance) than writing:
ComplexNumber complexNumber(1,2); // 1+2i
So, which elements are important in deciding whether something should be put behind an interface and when it shouldn't be put behind an interface?
Reasons to move to an interface are when it makes things simpler or reduces coupling. (Thats what an interface is for).
Reasons to move away from an interface are if it makes things more complicated or kills performance (but profile that to be sure). I'd argue that your IComplexNumber class actually makes the class heirarchy more complex unless you're introducing a MockComplexNumber, but I doubt such a class would be usefull... and it will probably make make things slower, but I'd measure that.
But don't think you need to do everything one way, or that your decisions are fixed in stone. It's pretty easy to convert to/from using an interface.
If you divide your classes into "service" and "value" classes, depending on the roles they play, then the answer is simple. Only use interfaces on service classes. In your question, "solver" is a service and "complex number" is a value.
Value classes should be easy to create using new() because they only accept basic types and other value classes in the constructor. Value classes are not useful to mock because you can use the real thing.
It may be useful to mock service classes and you may want multiple implementations. Your solverFactory could return a naiveSolver, a lookupSolver, a geneticSolver, a mockSolver etc. Here an interface is uesful.
With C++ it does not matter so as c++ has multiple inheritance and so an interface is an abstract class which you can add implemetation to. Where I have found interfaces most used is Java and C# which have single inheritance and if you wan a class to implement several things only one can be an abstract class the others must be interfaces
So I have a factory class and I'm trying to work out what the unit tests should do. From this question I could verify that the interface returned is of a particular concrete type that I would expect.
What should I check for if the factory is returning concrete types (because there is no need - at the moment - for interfaces to be used)? Currently I'm doing something like the following:
[Test]
public void CreateSomeClassWithDependencies()
{
// m_factory is instantiated in the SetUp method
var someClass = m_factory.CreateSomeClassWithDependencies();
Assert.IsNotNull(someClass);
}
The problem with this is that the Assert.IsNotNull seems somewhat redundant.
Also, my factory method might be setting up the dependencies of that particular class like so:
public SomeClass CreateSomeClassWithDependencies()
{
return new SomeClass(CreateADependency(), CreateAnotherDependency(),
CreateAThirdDependency());
}
And I want to make sure that my factory method sets up all these dependencies correctly. Is there no other way to do this then to make those dependencies public/internal properties which I then check for in the unit test? (I'm not a big fan of modifying the test subjects to suit the testing)
Edit: In response to Robert Harvey's question, I'm using NUnit as my unit testing framework (but I wouldn't have thought that it would make too much of a difference)
Often, there's nothing wrong with creating public properties that can be used for state-based testing. Yes: It's code you created to enable a test scenario, but does it hurt your API? Is it conceivable that other clients would find the same property useful later on?
There's a fine line between test-specific code and Test-Driven Design. We shouldn't introduce code that has no other potential than to satisfy a testing requirement, but it's quite alright to introduce new code that follow generally accepted design principles. We let the testing drive our design - that's why we call it TDD :)
Adding one or more properties to a class to give the user a better possibility of inspecting that class is, in my opinion, often a reasonable thing to do, so I don't think you should dismiss introducing such properties.
Apart from that, I second nader's answer :)
If the factory is returning concrete types, and you're guaranteeing that your factory always returns a concrete type, and not null, then no, there isn't too much value in the test. It does allows you to make sure, over time that this expectation isn't violated, and things like exceptions aren't thrown.
This style of test simply makes sure that, as you make changes in the future, your factory behaviour won't change without you knowing.
If your language supports it, for your dependencies, you can use reflection. This isn't always the easiest to maintain, and couples your tests very tightly to your implementation. You have to decide if that's acceptable. This approach tends to be very brittle.
But you really seem to be trying to separate which classes are constructed, from how the constructors are called. You might just be better off with using a DI framework to get that kind of flexibility.
By new-ing up all your types as you need them, you don't give yourself many seams (a seam is a place where you can alter behaviour in your program without editing in that place) to work with.
With the example as you give it though, you could derive a class from the factory. Then override / mock CreateADependency(), CreateAnotherDependency() and CreateAThirdDependency(). Now when you call CreateSomeClassWithDependencies(), you are able to sense whether or not the correct dependencies were created.
Note: the definition of "seam" comes from Michael Feather's book, "Working Effectively with Legacy Code". It contains examples of many techniques to add testability to untested code. You may find it very useful.
What we do is create the dependancies with factories, and we use a dependancy injection framework to substitute mock factories for the real ones when the test is run. Then we set up the appropriate expectations on those mock factories.
You can always check stuff with reflection. There is no need to expose something just for unit tests. I find it quite rare that I need to reach in with reflection and it may be a sign of bad design.
Looking at your sample code, yes the Assert not null seems redundant, depending on the way you designed your factory, some will return null objects from the factory as opposed to exceptioning out.
As I understand it you want to test that the dependencies are built correctly and passed to the new instance?
If I was not able to use a framework like google guice, I would probably do it something like this (here using JMock and Hamcrest):
#Test
public void CreateSomeClassWithDependencies()
{
dependencyFactory = context.mock(DependencyFactory.class);
classAFactory = context.mock(ClassAFactory.class);
myDependency0 = context.mock(MyDependency0.class);
myDependency1 = context.mock(MyDependency1.class);
myDependency2 = context.mock(MyDependency2.class);
myClassA = context.mock(ClassA.class);
context.checking(new Expectations(){{
oneOf(dependencyFactory).createDependency0(); will(returnValue(myDependency0));
oneOf(dependencyFactory).createDependency1(); will(returnValue(myDependency1));
oneOf(dependencyFactory).createDependency2(); will(returnValue(myDependency2));
oneOf(classAFactory).createClassA(myDependency0, myDependency1, myDependency2);
will(returnValue(myClassA));
}});
builder = new ClassABuilder(dependencyFactory, classAFactory);
assertThat(builder.make(), equalTo(myClassA));
}
(if you cannot mock ClassA you can assign a non-mock version to myClassA using new)
I'm writing in second-person just because its easy, for you.
You are working with a game engine and really wish a particular engine class had a new method that does 'bla'. But you'd rather not spread your 'game' code into the 'engine' code.
So you could derive a new class from it with your one new method and put that code in your 'game' source directory, but maybe there's another option?
So this is probably completely illegal in the C++ language, but you thought at first, "perhaps I can add a new method to an existing class via my own header that includes the 'parent' header and some special syntax. This is possible when working with a namespace, for example..."
Assuming you can't declare methods of a class across multiple headers (and you are pretty darn sure you can't), what are the other options that support a clean divide between 'middleware/engine/library' and 'application', you wonder?
My only question to you is, "does your added functionality need to be a member function, or can it be a free function?" If what you want to do can be solved using the class's existing interface, then the only difference is the syntax, and you should use a free function (if you think that's "ugly", then... suck it up and move on, C++ wasn't designed for monkeypatching).
If you're trying to get at the internal guts of the class, it may be a sign that the original class is lacking in flexibility (it doesn't expose enough information for you to do what you want from the public interface). If that's the case, maybe the original class can be "completed", and you're back to putting a free function on top of it.
If absolutely none of that will work, and you just must have a member function (e.g. original class provided protected members you want to get at, and you don't have the freedom to modify the original interface)... only then resort to inheritance and member-function implementation.
For an in-depth discussion (and deconstruction of std::string'), check out this Guru of the Week "Monolith" class article.
Sounds like a 'acts upon' relationship, which would not fit in an inheritance (use sparingly!).
One option would be a composition utility class that acts upon a certain instance of the 'Engine' by being instantiated with a pointer to it.
Inheritance (as you pointed out), or
Use a function instead of a method, or
Alter the engine code itself, but isolate and manage the changes using a patch-manager like quilt or Mercurial/MQ
I don't see what's wrong with inheritance in this context though.
If the new method will be implemented using the existing public interface, then arguably it's more object oriented for it to be a separate function rather than a method. At least, Scott Meyers argues that it is.
Why? Because it gives better encapsulation. IIRC the argument goes that the class interface should define things that the object does. Helper-style functions are things that can be done with/to the object, not things that the object must do itself. So they don't belong in the class. If they are in the class, they can unnecessarily access private members and hence widen the hiding of that member and hence the number of lines of code that need to be touched if the private member changes in any way.
Of course if you want to access protected members then you must inherit. If your desired method requires per-instance state, but not access to protected members, then you can either inherit or composite according to taste - the former is usually more concise, but has certain disadvantages if the relationship isn't really "is a".
Sounds like you want Ruby mixins. Not sure there's anything close in C++. I think you have to do the inheritance.
Edit: You might be able to put a friend method in and use it like a mixin, but I think you'd start to break your encapsulation in a bad way.
You could do something COM-like, where the base class supports a QueryInterface() method which lets you ask for an interface that has that method on it. This is fairly trivial to implement in C++, you don't need COM per se.
You could also "pretend" to be a more dynamic language and have an array of callbacks as "methods" and gin up a way to call them using templates or macros and pushing 'this' onto the stack before the rest of the parameters. But it would be insane :)
Or Categories in Objective C.
There are conceptual approaches to extending class architectures (not single classes) in C++, but it's not a casual act, and requires planning ahead of time. Sorry.
Sounds like a classic inheritance problem to me. Except I would drop the code in an "Engine Enhancements" directory & include that concept in your architecture.