Bit Motif

In the last year I’ve heard too much about POJOs. It has died down some, but I still hear it too much. Basically, I am sick of people saying POJO when they mean DTO.

The notion of a framework that works with your existing objects is great. And, if it actually does work with your existing objects, that’s even better.

But, when everything in my system–through ignorance and/or framework–has become a DTO, it kind of pisses me off.

I mean, why is there a setter there? Can the object change state during it’s lifetime? If so, why is there a setter? Why not some other name that doesn’t have to do with implementation? If not, why the hell is it there? Why is that getter there? Do we need to return that value? If so, why? Is somebody asking the object for something rather than telling it what to do? If not, why the hell is it there?

What I’ve heard a lot of is: “Just new up a POJO, and the FlarbleMeister framework will do the rest. It is freaking awesome.” Because of ignorance, framework, and ignorance of the framework, I have to deal with code from the database to the UI with nary a real object. You know, the stuff that can make code easy to work with, the stuff that helps explain the system and allow others (developers working on the code years from now) to intuit what is supposed to happen.

So, please think about it: Is this a real object or a glorified DTO? If it is a DTO, does it belong at this layer in the system? Does it make sense to have it at all? And, please, stop calling it a POJO.

The other day, my team was asking if we needed to have unit tests for our data structure classes that had only getters and setters. We were thinking more in terms of Test First Development/Test Driven Design. I was uncomfortable saying “no”, but I couldn’t say why. Most IDEs will generate these, so you don’t you shouldn’t have to worry about doing something wrong. The practical side of me was fighting with the Test First side of me.

I could see why one wouldn’t want to have tests for said classes. They suck to write, and are supposedly so simple you have high confidence that they work correctly. Still, it bugged me. Then, a teammate pointed out something. In these cases, the value of the unit test isn’t necessarily the design aspect. It is for future users. The test is a set of expectations for the data structure class, a set of expectations that all other classes it interacts with will have.

If you don’t have a test, when you make a change, you aren’t going to have confidence that everything is working as it should. With a test, you will know what the expectations are if you need to make a change. And, if you make a change to the data structure class without regard for the test, the existing test should give you some feedback, and a little more confidence.

In this case, I think the value is for future changes. It isn’t nearly as cool as having a test drive your design (which it still can), but it is just as important.

As to why we have all these, data structure classes and what I think of it, that’s another post…

Often, there’s an implication that everything being unit tested is on an equal footing. That isn’t the case. I think within unit testing there is a spectrum. On one end you may have a simple object on the other end you may have a more complex object composed of several other objects. For the simple object, state-based testing is easy and understandable. For the composed object, behavior-based testing becomes preferable.

Expanding on this, I’ve noticed that when I am just starting development, there are no mocks or stubs. As I progress, there are instances where I am using some stubs in tests. And when I almost have functionality, I am using mocks when testing. I use stubs at a “lower” level and mocks at a “higher” level.

I think that this makes sense. Once I’ve got my base set of objects, I just want to make certain that they talk to each other in the appropriate manner. I trust that the individual objects know what to do. At that higher level, it’s the interaction I want to test.

We can glean a lot of information about code from visual cues like number of lines in the file, the size of the blocks of text, number of blocks, and the consistency and amount of indentation.

• Bigger files — typically bad
• Bigger blocks of text — typically bad
• Lots of blocks of text — typically bad
• Lots of indentation — typically bad
• Inconsistent indentation — typically bad

Now, I don’t think that if any of the above are present, it is a metaphysical certainty that code is bad. And, just because some code does not have any of the above, I don’t think it means it must be good.

I do think they are good predictors. In my experience, the vast majority of the time if I see something that has all of the issues listed above, it is going to be difficult to work with. Conversely, if it is going to be easy to work with, it will typically have none of the aforementioned issues.

The other day I across some funky stuff in some code we inherited. It worked, but it wasn’t the cleanest or clearest way of doing things. I thought, “Well, I should probably refactor this.” The funkiness was at a high enough level that no unit test was going to explain what was going on. So, I went to the appropriate acceptance tests.

I figured I’d have enough information to know what was going on and to verify my changes didn’t break anything. The tests did provide some documentation, but it was really about the mechanics of what we were doing. I knew that I could make changes, but still felt a little uncomfortable. For me to be really comfortable making the change, I needed some context—the “why”.

I know others had a few of these uncomfortable moments with the code. A number of times we might have wanted to make a high level change, but because we didn’t know the “why”, we didn’t have the necessary confidence to do it.

This got me thinking about some aspects of the BDD-type stuff that I like. One of them is the whole “As a..”, “I want to..”, “So I that…” preamble for story frameworks (see RSpec or JBehave for examples). With some documentation about the roles, the actions, and the outcomes, you have that necessary context when you come back to the code several years later.

This context is absolutely needed at the acceptance test (story) level. At that level, it ceases to be about the units, and is about the whole. When we start making changes at that level, we need to know the “why”. Otherwise, our software just ain’t gonna be soft.

In the past month or so I’ve been working on a code base that’s been around the block a few times. Some of the code was inherited from other projects where it was already ancient. Other code is just code that has been in the project forever.

I’ve noticed that this code—production code and tests—is very chatty. I mean, I can’t run a test without War and Peace being written to the console. My guess is that this due poor tests.

When the code is unfamiliar, we have a few options to get our heads around it. The first and best option (in my opinion) is to run the code’s extensive and well-maintained test suites. The tests will serve as documentation for the code in its current state.

What if we don’t have those tests? I guess we start reading through the code, using the debugger, and output statements to the console. See where I am going with this?

Writing output/debug statements is fine for short-lived (think minutes) testing/code archeology. Once you answer your particular question, get rid of it. If you need that output to test something, put it in a test. If the output is something you’d like to have when the production code is running, log it. Either way, those output statements should not get committed.

Why? Software is complex. We try to reduce the complexity. Tests and production code that spew line after line to the console when it is not needed add complexity. Consider a test that prints a stack trace from an exception to the console, yet passes. How are you going to feel about the test? The production code?

Recently, I had the displeasure of adding new functionality to some very old code.

Since I develop test-first, I immediately went to the unit tests for this code and started looking around. I planned on modifying the existing tests, adding new tests, and refactoring along the way. This way, I would ensure the new functionality was working properly, and did not have any negative effects on the existing code.

I soon discovered that a number of the classes did not have any tests. Annoyed and disappointed, I set out to get some tests around the areas I was going to be touching. I decided I would go back and add more tests for other parts of the code if I had time.

As I worked, I was amazed at how difficult it was to get tests around the code. Strange dependencies, improper abstractions, and duplicated code hampered my attempts to test. Eventually, I made the tests I needed and left the code a little better than when I got there.

This experience reminded me of an old adage:

Listen to your tests.

Your tests can tell you a lot about your code, and not just in the “this method returns the input multiplied by 2″ kind of way. By examining what you must do to create a test you can learn much about the code’s dependencies, abstractions, and interactions.

Do you have to make all sorts of funky objects to test something? Is it impossible to test something “straight on”? Do the assertions you make in one class’s tests look pretty much like the assertions in another class’s tests? Do your tests take a long time to run? If you answer yes to these questions, your code is probably hard to test.

All of which leads me to another old adage:

If your code is hard to test, it probably sucks.