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.

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.

When I hear something like “We don’t need to test it. It’s declarative.”, I cringe. Sometimes it’s true, sometimes not. Like most engineering decisions, It’s really a matter of context, a matter of risk and effort.

Computers do what you tell them to do. How do you know that what you are telling them to do is the right thing? Sometimes the issue is that the computer is doing exactly as you declared! We need to keep that in mind when we think “Oh, don’t worry about that. It’s declarative.”

Assuming that our stakeholders are comprised of customers, developers, testers, database, support, and deployment working in their own silos, what is the common ground between any two?

Worst case:

We can see that in a worst-case, siloed organization, the conduit for communication can differ. Even between two stake holders, the conduit can differ depending on the flow of information (e.g., the conduit between Customer and Support is not the same as Support and Customer). Each conduit is a chance for miscommunication.

So, the common ground between any two can vary. What if we have an idea or issue that spans several silos? More and possibly very different artifacts will have to be taken into account. Because these artifacts were created by different groups, there’s a good chance there is going to be miscommunication and wasted effort.

Now, let’s tweak the terms like “Requirements”, “Application”, “Bug Report”, and “DB Schema” for a best-case description of said artifacts/conduits:

Requirements: Description of what the Application should do with runnable examples and text
Application: The system that will be deployed for users, as well as all the tests, set up scripts, etc
Bug Report: Automated, report-as-soon-as-you-find-it test failure
DB Schema: The DDL and DML used in the database in support of the Application

What we really need is something that takes the best-case description of the artifacts and holds them in a common area for all of the stake holders. This common area would be the spot where we all can talk the same talk, manipulate the necessary artifacts, and if need be, see the appropriate “view” (as a Customer, as Tester, etc…) of the software as a whole.

Where/what is this commons? Well, it doesn’t fully exist yet. Things like Fit, FitNesse, and BDD almost get us there. The next generation of tools such as Twist get us even closer.

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.

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.

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.

He related an opinion he had received regarding the most important agile principle:

A commitment to continual improvement

Or taken from the Principles behind the Agile Manifesto:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

I believe that if we are serious about producing software that meets our customers’ needs, all other practices and ideas can be traced back to this. If you can’t trace a practice back to continual improvement, or if a practice/principle leads to an improvement, but cannot be extended, then you aren’t going to see real, lasting, long-term improvement.

Too often, when we tackle a larger-scale problem–say something that is at a multi-team level–we don’t keep the idea of continual improvement in mind. Decisions are made that don’t take into account that we want to be able to improve even more sometime in the future. This leads to periods of improvement, followed by a plateau, followed by some backtracking, and then a new improvement.

If we want to reduce this plateau/backtracking, we must keep in mind that we want our decisions to be in accordance with our need to constantly improve.

Let’s look at a super simple description of software development roles and their artifacts:

Customer: requirements, acceptance tests
Developer: code, unit tests, module tests, acceptance tests
Tester: module tests, acceptance tests

See the overlap? If customers, developers, and testers aren’t working together, we are creating waste through duplication. Even if we are working together, we can do better.

What if worked in such a way that the customer requirements can be run as the acceptance tests and acceptance tests can be viewed as customer requirements? What if architectural requirements can be run as unit tests or module tests? Or, vice-versa?

You can see where I am going with this. We are still creating a lot of waste because of duplication. If we can work within some framework (that doesn’t necessarily mean a tool) that seamlessly allows us to have requirements as tests and the other way around, and reuse tests between customers, testers, and developers, we can make some real gains in efficiency.

Furthermore, working in this manner reduces duplication in communication. Everybody is working with the same “stuff”. This “stuff” serves as documentation as to the expected behavior and real behavior of the system. There should be less time spent talking about the same thing amongst the various roles.

We are all essentially working on the same “stuff”. So, why not act like it and identify areas of duplication and reuse?

So, let’s make another simple example that uses Selenium. That way, we have real feel for the mechanisms we would use.

We’ll start once again with our scenario:

Given I am on “http://www.bitmotif.com”
When I click on link “Test Page For Selenium Remote Control”
Then the title is “Bit Motif » Test Page For Selenium Remote Control”

This scenario needs to be saved in a file named “navigation_scenario”.

Using the same approach we took in the previous post, we’ll create our scenario:

package com.bitmotif.jbehaveexamples.part.two;

import org.jbehave.scenario.Scenario;

public class NavigationScenario extends Scenario {
   public NavigationScenario() {
      super(new NavigationScenarioSteps());
   }
}

And, we’ll create our scenario steps:

package com.bitmotif.jbehaveexamples.part.two;

import org.jbehave.scenario.steps.Steps;
import org.jbehave.scenario.annotations.*;
import org.junit.Assert;

public class NavigationScenarioSteps extends Steps {
   private SystemUnderTest system;

   @BeforeScenario
   public void startSystem() throws Exception {
      system = new SystemUnderTest();
      system.start();
   }

   @AfterScenario
   public void stopSystem() throws Exception {
      system.stop();
   }

   @Given("I am on \"$url\"")
   public void startOnUrl(String url) {
      system.open(url);
   }

   @When("I click on link \"$linkText\"")
   public void clickLink(String linkText) {
      system.clickLink(linkText);
   }

   @Then("the title is \"$title\"")
   public void checkTitle(String title) {
      Assert.assertEquals(title, system.getCurrentTitle());
   }
}

This time around we need to make certain we have the ability to start and stop our system. We annotate the starting and the stopping of the system, so we know the state of the system when we run.

Like I said before, we have a system under test that is “real”. In this particular case, our system is really a pass-through to Selenium Remote Control:

package com.bitmotif.jbehaveexamples.part.two;

import com.thoughtworks.selenium.Selenium;
import com.thoughtworks.selenium.DefaultSelenium;
import org.openqa.selenium.server.SeleniumServer;

public class SystemUnderTest {
   private static final String MAX_WAIT_TIME_IN_MS = "60000";
   private static final String BASE_URL = "http://www.bitmotif.com";

   private Selenium selenium =
      new DefaultSelenium("localhost", 4444, "*firefox", BASE_URL);
   private SeleniumServer seleniumServer;

   public void start() throws Exception {
      seleniumServer = new SeleniumServer();
      seleniumServer.start();
      selenium.start();
   }

   public void stop() {
      selenium.stop();
      seleniumServer.stop();
   }

   public void open(String url) {
      selenium.open(url);
   }

   public void clickLink(String linkText) {
      selenium.click("link=" + linkText);
      selenium.waitForPageToLoad(MAX_WAIT_TIME_IN_MS);
   }

   public String getCurrentTitle() {
      return selenium.getTitle();
   }
}

With this in place, we can run our scenario. Tres cool.