How to write untestable code
googletesting.blogspot.com
googletesting.blogspot.com
which, desarcastified, I take to mean:
"Don't defensively assert about the state of parameters passed in methods, constructors, and mid-method."
Specifically:
"You see, there are testing freaks out there that like to instantiate your object, or call a method under test and pass in nulls"
Isn't it the case that a calling a method with (say) null parameters where they are supposed to be non-null should raise an exception? Isn't an assertion failure reasonable in this case?
I understood and agreed with a lot of the other stuff (although it struck me as a bit dogmatic) but this one I don't get.
Agreed that the whole article would be more useful without the sarcasm.
The tests are not the goal - a working product is. That's just making a trade-off between less lines in a test -vs- code that doesn't explode mid-transaction when that null suddenly occurs in a real-world scenario. If I'm supposed to write my code properly, testies should not be too lazy while writing the tests.
I have found that with a test framework like EasyMock, you no longer have to jump through so many of these goofy tdd hoops. You can mock methods, return values, thrown exceptions, parameters to methods to another object inside a method, etc. It still doesn't warrant writing crap code using anti-patterns, but nevertheless, it makes life more bearable by putting the focus back on the logic at hand and less on trying to follow the tdd mantra of design.
1. If you are going to assert these things, don't do it in the middle of the method - do it in a place that makes sense (start of the method).
2. One of the members of my team likes to make assertions about parameters that aren't actually valid but just sound like they are, for example, wrapping the entire code in a method with an int id parameter with a
if (id > 0) {
...
}
So in other words, having a bunch of unnecessary assertions that spring up in seemingly random places makes your code hard to test.
Sure, I can see that -- assertions in the middle of a method might well indicate that maybe that bit should be split into more than one method.
But the article goes further than that: they seem to complain about assertions guarding parameter values. I really don't get that. Actually, I'll go one further: complaining about that is unjustifiable.
Anyway, I also don't always get the particular flavour of OOP dogma that Java devs sometimes seem to promote. It certainly feels different to me from Python world, and I suppose it is.
When I see the phrase "silently does nothing" I feel vaguely uneasy.
Not really. Checking parameters in every method (especially an OO system) is a sure way to have poor performance. Null values as other kinds of testing should be done in the areas of the system that create and receive objects from outside.
Normal methods should just work find even if a parameter is NULL. Although this doesn't look nice, it is a way to make the system testable, in the absence of true NullObjects.
This seems overly general to me. I'm not sure it's a "sure way to have poor performance." It seems to me that (for example) a null-check is pretty fast.
> Normal methods should just work find even if a parameter is NULL.
What's a "normal method"? And if the business logic of the method requires a particular parameter to be non-null (or has some other constraint), what should happen when a null parameter is passed-in (by a test or otherwise)?
> Be Defensive [...] Defensively assert about the state of parameters passed in methods, constructors, and mid-method. If someone can pass in a null, you've left your guard down. You see, there are testing freaks out there that like to instantiate your object, or call a method under test and pass in nulls!
I'm not sure what he wants to change. Surely if the code would crash when I pass a null as an argument, it's better to make it throw the exception as early as possible. You can test that by asserting an exception when you call that_func(null);.
Why is that a bad thing? (Or did I misunderstand him?)
I thought "having testable" code, is never the end, maybe the means perhaps, but not necessary,
If you have done mobile development, you know you have to break most of these rules at some point. Sorry, I'd rather have a shipping/peformant product, than one that is a hog, but makes OO purists happy, and is easy to test.
At the end of the day, keeping your customer happy, that is the end game.
Create Utility Classes and Functions/Methods - For instance, you have a String which is a URL you're passing around (obeying "Use Primitives Wherever Possible"). Create another class with static methods such as isValidUrl(String url)
if the function is a deterministic function (I guess it could be implemented as a simple test against regex) why is is difficult to test? I get that its better to use the system one or your own URL class, but thats really about OO and not testing!
Loosely coupled objects will allow you to do that, but how would you redefine the behavior of something static?
For example, the advice to not "instantiate objects using new in the middle of methods" wouldn't be a big deal if if your test code could easily instruct the compiler to replace the concrete object with a mock when the test is run.
Makes me glad I'm not writing Java, fewer than half of these are problems for me.
OO cowboys will want to have a whole polymorphic soup of collaborating objects
Of Course! When I implement, say, Bubble Sort, I do not implement the classes BubbleList with the methods sort and addObject: anObject and BubbleObject with the method bubbleMaybe: aBubbleList, just to see my tests for BubbleObject fail when I switch to Quicksort.
x_factory_proto :: GlobalParams -> InitParams -> X
...
x_factory = x_factory_proto some_params