Could someone explain: "Be Defensive - They're out to Get Your Code! - Defensively assert about the state of parameters passed in methods, constructors, and mid-method."?<p>which, desarcastified, I take to mean:<p>"Don't defensively assert about the state of parameters passed in methods, constructors, and mid-method."<p>Specifically:<p>"You see, there are testing freaks out there that like to instantiate your object, or call a method under test and pass in nulls"<p>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?<p>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.
Could someone explain this one?<p>> 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!<p>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);.<p>Why is that a bad thing? (Or did I misunderstand him?)
I'm pretty sure this was copied word for word from the employee guide of the firm that originally wrote the software I now trudge through every day. Except it wasn't sarcastic. And I think there was some other rule in there about avoiding spacing in the source code at all costs.
Jesus, basically don't worry about the product, just worry about having testable code.<p>I thought "having testable" code, is never the end, maybe the means perhaps, but not necessary,<p>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.<p>At the end of the day, keeping your customer happy, that is the end game.
What's wrong with<p><i>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)</i><p>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!
It's too bad Java/C++ were designed after unit testing became commonplace. Some of the advice here will actually improve your production code but a lot of this is just a case of the programmer having to work around the language.<p>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.
A little too vague - don't use if? switch? Surely they are useful. Better to advise against putting application logic into the wrong object - which is what I THINK they are arguing against.
<i>Greenlight if-branches and switch statements<p>OO cowboys will want to have a whole polymorphic soup of collaborating objects</i><p>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.
Some pretty darn good advice in here. This might be slightly embarrassing, but it actually makes me appreciate the value of Factories; something I always thought was a little overkill for anything but GUI code.