Over the last few weeks, my team has spent time refocusing on communication within the team as well as with our customer proxy. For various reasons, we had become a very siloed. There was little communication with our customer and only little more communication between team members–primarily among individuals that had to make their pieces of code talk to each other.

We’ve gone back to tasking out work on a regular basis. In the course of doing this, we all are talking about what’s there, what’s needed, what we understand, what we don’t understand. With this, we were able to figure out what we could comfortably commit to. Then, we worked with our customer proxy while we developed. This was done in conjunction with our normal code review/refactoring sessions. Lo and behold, the iteration went smoothly.

I hope the rest of the team feels the same way. I know from a lead/senior development perspective, it was less painful (almost fun!) than previous iterations. I’d almost forgot what a little communication can do.

Too often, I hear people say “It’s test code, don’t worry about it.” Well, I disagree. I think the quality of your test code is reflective of the code base in general. The same issues that we have have with the test code we will have with production code. If you see duplication, high complexity, low cohesion, etc. in the tests, odds are you are going to see it in the production code base.

The tests and the supporting code need to be well factored. If a “small” change in the production code is going to result in a large amount of painful changes in test code we are less likely to make the proper changes. And thus begins the downward slide.

It is better to apply DRY and SOLID principles every time we write test code. We get more time practicing the discipline needed to write quality code, and we set ourselves up for an easier time in the future.

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.