My personal pet hate is functions like this

x = rand()

Its both a command and a query, and difficult to unit test.

In reality, it should be an iterator

x = random.value()
random.move_next()

Then you can test it.

The other advantage of command query is you can write code in this way.

if x.invalid():
do_something()
else:
x.calculate()

instead of

try:
x.calculate()
except:
do_something()

I personally don’t like exceptions being use for flow control, unless you really, really need to. e.g. Inverting a matrix where the query on the matrix, is_inveritable() is very computationaly expensive.

Microsoft are awful at not having Command-Query separation.

Next stop, a decent design by contract implementation in dot net.

Nick

The side-effects of the Stack methods are simple and restricted to the instance, and hence straightforward to test.

The bad OOP approach (and the test-killing approach) is to just put a List in your business logic class, and *treat* it like a stack — pushing items into one end, pulling them back out and deleting them…. Moving *that* code into a clean stack object puts a bunch of code into the realm of easy test coverage.

[Of course, it's even better just use the stack impl likely built into your language of choice.. but hey, we're talking concepts here.]

Thanks, great article… ;]

I would assert that, contrary to the static method example given as a “good idea”, static methods and instances are a BAD idea in OOP, especially when it comes to testing. Static methods cannot (easily) be substituted by the test code to force certain code paths to be tested, and static variables are difficult to properly test.

Testing in an OOP language should be easy - create the object, set it to a known state, invoke the method, and inspect the new state. Problems with testing tend to arise in a couple of areas: (1) creating the object is a laborious and tedious task, generally because the object is complicated and/or poorly designed; (2) the object exhibits poor cohesion and widespread coupling; and (3) the object’s state is difficult or impossible to determine or interrogate.

(1) is an effect of leaving testing to a later part of the development cycle; testing early in the development cycle encourages the developer to make their life easy when it comes to creating an object with a known state. Sometimes what is required is a builder-pattern, where a complicated configuration string (structured-key-value-pairs or XML or S-expressions or P-lists) can be provided to a helper class that spits out the appropriate object.

(2) is quite simply a design problem, often due to (in my experience) insufficient foresight or excessive fondness for the code. (Sometimes, you just have to throw the first one away. If the cookies give you indigestion, frosting won’t help.) Foresight is wonderful, but not dependable; it can warn you away from problematic paths, but it can’t guide you towards the minimum-effort-maximum-success path in the general case.

(3) is a natural consequence of (2), but it also a natural consequence of hurried development, sloppy development, poor or inexperienced developers, and (what I call) demo-driven implementation. When you’re trying to get some code out the door yesterday, it’s natural to not think about testing, documentation, cohesion, coupling, appropriateness or lack of same of the “static” keyword, etc. It’s natural. But it also causes problems down the line. The way to deal with this is to have a strong aesthetic (if you puzzle out what a method does, do you write a summary comment for that method? If not, why not — should the next programmer have to duplicate all of your effort? Why?) and to, naturally, never forgo testing.

I just wish I were better at paying attention to my own advice.

A stack seems fairly easy to test; perform operation, check element on top and bottom of stack, and count of items in stack. That would reasonably assure that your stack is working correctly. Am I missing something?

Overall I agree that creating a side-effect-free non-trivial object is harder than isolated functions or FP-oriented code.

I am often asked: “How can I test this method - it’s untestable/too hard to test?” The implication, there, is that testing is too hard or impossible in certain situations. While the asker of said question is often right, the (un)testability of the code in question is nearly always a result of problematic design. When code is written without consideration for testing, it becomes easy to get trapped in a mess of untestable code. It makes sense - if you’re not thinking about it, why would your code turn out testable?

Testing is a necessity (no space to prove that statement here), so testability is a requirement. If your code is untestable, you haven’t met the testability requirement. No matter what you think of it, test driven development is a near sure fire way to ensure testability. Because you write your tests first, you can’t (or are far less likely to) trap yourself in a an untestable situation.

As far as side effects are concerned, with respect to classes, just treat the internal state of the class as though it were the method’s parameters, and return values. Whether the input comes from a class-scope variable, or is passed in to the method through arguments is irrelevant. Find a way to reproduce each potential situation in isolation (typically using mocking). Mock out any external dependencies. Then, you’ll have a side-effect free method (effectively).

For example, if you want to test an implementation of a stack, I don’t quite see, how you can implement this side-effect free. Unless, you use a functional programming language in the first place, of course.

I once tried this approach myself but eventually gave it up.

In OOP language, side-effect-free methods break the rule of “low coupling, high cohesion”.
Methods in an object should be cohesive to each other, which means that they should share instance variables.
Math.sqrt is a static method and doesn’t have to be cohesive.

More concretely, if methods are not cohesive, they will unnecessarily have more parameters like in procedural language.

“Maybe I am stupid but I see only one use case for a test - that is to ensure that your application is running as expected on other machines as well. I dont believe that anyone who does intensive testing wasn’t a professional coder who has to use tests anyway for various reasons.”

On a large application with a lot of developers, you’d be surprised how easy it is to change a single function and break your application in completely unexpected places, many of which you’ve probably never even seen before. Having a strict automated nightly build process in conjunction with unit tests is basically the only way you can control this with any confidence - it is impossible to re-test everything by hand every time a change gets made. Writing decent tests ma seem like a waste of time if you’re working in a small team, but it can save weeks/months on larger projects.

“Anyone who has tried to test a sufficiently complex class will find that the amount of work to set-up the internal state of an object to test a single use-case for a method prevents even the most keen programmer from doing so.”

Sounds like poor class design or laziness on the part of the developer. The reason most developers don’t want to create repeatable tests (and I am guilty of this as well) is that it’s boring. Not testing stuff because “it’s a lot of work to set it up” is the same as a little kid stamping his foot on the ground and saying “I don’t wanna!” when asked to clean his room.

If writing tests in OOP languages is so useless, why do so many people do it?

Testing OOP languages is almost useless (IMO) since every method by definition should either alter state or return different results based on state. Anyone who has tried to test a sufficiently complex class will find that the amount of work to set-up the internal state of an object to test a single use-case for a method prevents even the most keen programmer from doing so.

But when I actually go and read test stuff for a programming language, they seem to rather focus their minds on the whole testing aspect.
Do they not allow that, if you use objects for a long time in their “expected” use area, these object will specifically work very well, simply because author(s) improved them over time?

Recently a few of us (3) finished a small game project. It was inspired by a python blog, where someone wrote about a 48 hours game project (ours was only 6 hours but it was still interesting).

There were 0 tests involved, but the game works (has only 12 .rb files and about 16 classes).