The next time you are about to extend a class, stop and think about who is going to be consuming this extended class. If the extended class (instead of the base class) is in the contract amongst collaborators, why the extension?

If, somewhere along the line, you want your extended class to be used (consumed) as the base class, go ahead and extend. If that isn’t the case, then maybe composition should be preferred.

It really comes down to this:

Extension is about consumption.

Quick–how many of your tests would fail if you were not connected to a network (for database, files, services, etc)? How many of these are labeled as “unit tests”?

Do you have a way of quickly determining which tests are dependent upon that network connection? Can you easily run all the tests that aren’t dependent upon the network? Do you find that there are errors/failures in surprising areas?

Try it and see. You may learn something interesting about your code’s dependencies.

Quick–when was the last time you just deleted the directory for you project(s)? Could you do it right now without any problems? What would you need to recreate your set up?

Once you have your setup, it seems pointless to spend any more time trying to make it easier/faster to create said setup. And maybe it is for *you*. But, the next person coming along probably won’t consider it pointless.

Be hardcore. Purge that stuff right now and see what you need to do to get going again. You’ll find out quickly what you (and your new team member, your CI, your deployment team, etc) need.

In the past couple of months, I have run into a few nay-sayers while attempting to build some test infrastructure. Many times, when I propose a change, the response I get is basically this:

We could probabaly do that, but it would be hard.

Well, duh. That is why we get paid. If it was easy, we wouldn’t have a job. If at any given time you know the solution to all the problems facing you at work, you can be automated out of a job.

Maybe the reluctance is a form of job security. But, I don’t think that holds, either. Why? Because there are always problems to solve. Solving a difficult problem frees you up to solve even more difficult problems. If you are always doing that, I don’t think you’ll have a hard time keeping your job.

Now, I’ll do the disclaimer-type thing. I am not saying we should do something just because it is hard to do. But, in life many things worth doing are difficult. And, if somebody doesn’t know how to do this difficult thing, they hire people like us.

So, be glad it is difficult.

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.