Be Glad It Is Difficult

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.

JBehave Rave

I attempted to use JBehave almost a year ago, but found it difficult to work with. In the last two months, however, JBehave 2.0 and JBehave 2.1 were released. These releases represent a fundamental change in how JBehave works, and are supposed to make using JBehave easier. I thought I’d try JBehave again. And, man oh man, it is so much better! Here are my notes.

Getting Started
In order to use the latest JBehave you need to be using Java 1.5 or greater. If you want to use JBehave with your IDE, you’ll need to make sure you are using JUnit 4. You can download JBehave here.

Creating the Tests
We’ll create a text file for the scenario using the words Given, When, Then and And.

Given the basic data set exists
When I do the basic work action
Then the basic result occurs

We need to save the scenario in file. The file should have a meaningful name, but use lowercase letters and underscores, eg: basic_work_scenario

Let’s develop a simple heuristic: basic_work_scenario describes some basic work scenario. Something happens. Causing other things to happen. One step leads to another.

In our code, then, we need a class that reflects the name of the text file:

package com.bitmotif.jbehaveexamples;

import org.jbehave.scenario.Scenario;

public class BasicWorkScenario extends Scenario {
}

With that in place, we should be able to run the scenario. In your IDE, select the BasicWorkScenario class and run it.

If you see something like

org.jbehave.scenario.errors.ScenarioNotFoundException:
Scenario com/bitmotif/jbehaveexamples/basic_work_scenario could not be found by classloader sun.misc.Launcher$AppClassLoader@a9c85c

That means the text file with the Given/When/Then could not be found. The easiest way to do this is to make sure the file is placed along with the compiled classes. In Intellij, I just set the compilation option to take anything: *?.

Now, when we run, we see something like this

Scenario:

Given the basic data set exists (PENDING)
When I do the basic work action (PENDING)
Then the basic result occurs (PENDING)

We now have an outline of what we expect to see, as well as what has been implemented in the scenario. We haven’t implemented anything, so it is still pending. Also, note that you got a green bar.

Let’s continue developing our heuristic. Scenarios have steps, right? So, in our case the BasicWorkScenario has steps BasicWorkScenarioSteps. We need to create BasicWorkScenarioSteps. And, it turns out in JBehave, steps are a type. So, we also have:

package com.bitmotif.jbehaveexamples;

import org.jbehave.scenario.Scenario;

public class BasicWorkScenarioSteps extends Steps {
}

We can integrate our BasicWorkScenarioSteps with our BasicWorkScenario like this:

package com.bitmotif.jbehaveexamples;

import org.jbehave.scenario.Scenario;

public class BasicWorkScenario extends Scenario {
   public BasicWorkScenario() {
      super( new BasicWorkScenarioSteps() );
   }
}

If we run this, we still get a green.

We still don’t have anything interesting. Our BasicWorkScenarioSteps needs to contain the steps needed for the scenario. This translates to:

package com.bitmotif.jbehaveexamples;

import org.jbehave.scenario.steps.Steps;
import org.jbehave.scenario.annotations.Given;
import org.jbehave.scenario.annotations.When;
import org.jbehave.scenario.annotations.Then;

public class BasicWorkScenarioSteps extends Steps {
   @Given("the basic data set exists")
   public void createBasicDataSet() {
   }

   @When("I do the basic work action")
   public void basicWorkAction() {
   }

   @Then("the basic result occurs")
   public void checkResult() {
   }
}

Note the annotations and how they tie to our original text. If we run the scenario, we still get a passing run. Let’s see something interesting. What happens if we put in assertions that fail?

package com.bitmotif.jbehaveexamples;

import org.jbehave.scenario.steps.Steps;
import org.jbehave.scenario.annotations.Given;
import org.jbehave.scenario.annotations.When;
import org.jbehave.scenario.annotations.Then;
import org.junit.Assert;

public class BasicWorkScenarioSteps extends Steps {
   @Given("the basic data set exists")
   public void createBasicDataSet() {
      Assert.assertTrue(false);
   }

   @When("I do the basic work action")
   public void basicWorkAction() {
      Assert.assertTrue(false);
   }

   @Then("the basic result occurs")
   public void checkResult() {
      Assert.assertTrue(false);
   }
}

When we run this, we get the following:

Scenario: 

Given the basic data set exists (FAILED)
When I do the basic work action (NOT PERFORMED)
Then the basic result occurs (NOT PERFORMED)

java.lang.AssertionError:
	at org.junit.Assert.fail(Assert.java:91)
	at org.junit.Assert.assertTrue(Assert.java:43)
	at org.junit.Assert.assertTrue(Assert.java:54)

That’s a little more interesting! Note that after the first failure, the subsequent steps are not run.

Now, let’s hook up our scenario to a “real” system. For our purposes, we have two pieces we need to hook in: the system under test, and our data source. We’ll create these:

package com.bitmotif.jbehaveexamples;

public class StubbedDataSource {
   private boolean basicDataSetCreated = false;

   public boolean createBasicDataSet() {
      basicDataSetCreated = true;
      return true;
   }

   public boolean isInBasicState() {
      return basicDataSetCreated;
   }
}

And

package com.bitmotif.jbehaveexamples;

public class StubbedSystem {
   private boolean actionWasSuccessful = false;

   public boolean performBasicWorkAction() {
      actionWasSuccessful = true;
      return true;
   }

   public boolean isInBasicState() {
      return actionWasSuccessful;
   }
}

We’ll need to modify BasicWorkScenarioSteps like this:

package com.bitmotif.jbehaveexamples;

import org.jbehave.scenario.steps.Steps;
import org.jbehave.scenario.annotations.Given;
import org.jbehave.scenario.annotations.When;
import org.jbehave.scenario.annotations.Then;
import org.junit.Assert;

public class BasicWorkScenarioSteps extends Steps {
   private StubbedSystem system = new StubbedSystem();
   private StubbedDataSource dataSource = new StubbedDataSource();

   @Given("the basic data set exists")
   public void createBasicDataSet() {
      Assert.assertTrue(dataSource.createBasicDataSet());
   }

   @When("I do the basic work action")
   public void basicWorkAction() {
      Assert.assertTrue(system.performBasicWorkAction());
   }

   @Then("the basic result occurs")
   public void checkResult() {
      Assert.assertTrue(system.isInBasicState());
      Assert.assertTrue(dataSource.isInBasicState());
   }
}

And when we run it, we get green. We’ve essentially done the old “fake until you make it” routine. If we wanted to, we could now move toward swapping in a real data source (perhaps a database?) and real system to test.

Conclusion
The new JBehave is much easier to work with than its predecessor. When it comes to BDD, Java is now a first class citizen.

Enough With The POJOs!

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 Forgotten Value Of Unit Tests

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…

A Time To Stub, A Time To Mock

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.

Visual Inspection of Code

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.

Taken Out Of Context

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.

From Customer-Approved Software To Customer-Written Software

When we talk about customers with respect to an agile methodology, we often talk about people who have the final say in what is going to be produced and when.

Customers make decisions based on feedback from sources such as the current application, the tests for the parts of the application that are currently under development, their future needs, and what the development team says they can do in an iteration. The end result should be customer-approved software.

The implementation of the system outlined above may vary, but they key features remain. And, I think too often there is an implication that there is a distinct wall between producer (development team) and consumer (customer). The development team makes the stuff and the customer must approve it.

Contrast this with another approach to creating customer-approved software: have the customer write the software. Supposing the customers are savvy enough and/or have the right tools, if they write the software, it would be customer approved, too.

I actually worked at a place where this was the case. The first release of the product was written in a scripting language by industrial engineers that knew the domain. And, you know what? It worked. It did what they needed it to do at the time.

Notice I said “at the time”. As time went on, keeping the software “soft” proved to be difficult. Maintainability, extensibility, and testability went out the door. I don’t blame the people that wrote it. That kind of stuff is really part of the software development trade. In fact, I believe that if some sharp developers had been involved earlier, there would have been few issues.

What if the customer is not savvy enough? Provided we are always striving to improve our software and development process, I think eventually they will be. The longer we work with a customer, the more likely we will be creating tools for the customer to write some of the software themselves.

I am seeing hints of this at my current employer. On one of our projects we’ve reached the point where we have DSL for describing and testing our system that is used by developers, testers, and business analysts. We have super-tight iterations, with very few defects. If we are going to take a next step, it seems that step would be to use the DSL to create production code. It’s the next logical step.

Shut the Hell Up!

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?

It Takes At Least A Generation

Why is agile still such a foreign concept? Many software shop are familiar with the name, and some even claim to be agile. Yet, very few are.

In many places that claim to be agile, rather than collaboration amongst stake holders, there’s conflict. The process is more valuable than working, deliverable software.

“We can’t release your well-tested, customer-requested, money-saving feature now.”
“Why?”
“Because we only release 3.2 times a year, per our process. This release would violate the process.”
“Process? 3.2?”
“Yes. The process keeps us agile and the .2 helps gives us some buffer.”
“I don’t even know what that means!”

When does this silliness end? My guess is about one developer-to-leader generation. The developers that experienced an agile working environment will want to take it with them as they start leading others. But, that’s only when you’d start seeing some changes.