Test Infected

Installing SQL Server 2008 with Visual Studio 2008 SP1

2009-04-09T22:31:00.000-07:00

When I brought up my most recent Windows development machine (on Vista Ultimate), I installed Visual Studio 2008 Professional with SP1 embedded. Later, I went to install SQL Server 2008 including the "Management Tools" option so that I could have SQL Profiler and the other tools. That's when the problems started. The installation was blocked failing this rule:


Rule "Previous releases of Microsoft Visual Studio 2008" failed

Imagine my surprise when I found this article indicating that the problem was that I didn't have VS 2008 SP1 installed. I'm sure that I was running SP1, because I was seeing SP1 bugs manifested (requiring hotfixes). These bugs were only present in SP1 as of the time of this writing. It seems that a required registry key or something didn't get set when I installed Visual Studio. I really didn't want to get into hacking on the registry.

Solution

I downloaded the Visual Studio 2008 SP1 installer and ran it. This took quite a while, and I'm now up much later than I planned. However, I can report that this got me past the installation block. I'm not sure if I'll have to reinstall those hotfixes or not...

Happy coding!

Standing on the Side of Right

2009-03-11T08:17:00.000-07:00

Anyone that has worked with me will tell you that I am passionate about getting things right. I like to fix things that are broken. I like to improve my skills. I like to challenge others around me to improve and I expect them to do the same for me. I rarely miss the opportunity to improve myself or to encourage others to prove. I love teachable moments.

This morning, after reading Alan's thoughtful post on sexual harassment in the IT industry, I wonder where I have missed those teachable moments in the non-technical areas of my career. Though I don't have any women on my current team, I have worked with them in the past at other jobs. Though I have never done anything as egregious as what Alan describes, I hope that I have treated them with respect and dignity. I believe that I have. However, I am sure that I have also missed opportunities to help men around me be respectful, considerate, and just plain decent.

Though the original article was about sexual harassment, this is an issue that transcends gender. Sexual harassment is merely a single form of being a jerk. At my company, like many others, there are rules against being a jerk about certain taboo areas: gender, religion, age... We shouldn't be relying on corporate policy to define decency.

True confession time. I'm an ass. I hope that today I am less of an ass than I was ten years ago. But, truth be told, I still have some ass-like tendencies that pop up when I least expect them. I hate that.

Some of you know me well enough to know my beliefs. I am happy to say that I am a follower of Jesus Christ and that I have trust in Him alone to guide me through this life and the next. If my beliefs are to be consistent with my actions, then I must continue to fail forward in this area of how I treat those around me. To be consistent, I must treat everyone with respect and encourage others to do the same. To be consistent, I must be willing to admit when I am wrong (often). To be consistent, I must build other up rather than tearing them down. To be consistent, I must treat people like... people.

That brings me back to the original topic of this post. We must treat our female peers with the respect that they deserve, and we must insist that others do as well. Look around you. Are you standing up for others? Are you defending the sanctity of the lives around you? Where, dear reader, do you need to improve?

When Collections Are Configuration - binding Collections in Guice

2009-01-31T13:47:00.000-08:00

Classes that create their own internal domain objects and simple objects are typically not a problem for testability. The problem comes when classes are creating their own dependent services internally. Then, you've got a problem cutting the testing seams. Creating these dependent services is what Dependency Injection is best at. Using your IoC container to create everything constitutes container abuse.

However, I will use my IoC container of preference to create populated collections if the contents of those collections are inherently configuration. For instance, assume we have the following class:


public class Validator<T> {
  private Collection<Validation<T>> validations;
  private ValidationProblemReporter reporter;

  public Validator(Collection<Validation<T>> validations, 
    ValidationProblemReporter reporter) {
    this.validations = validations;
    this.reporter = reporter;
  }
  
  public validate(Collection<T> elements) {
    for(Validation<T> validation : validations) {
      for(T elements : elements) {
        if (!validation.isValid(element)) {
          String m = element.toString() + " fails " + validation.toString();
          reporter.reportProblem(m);
        }
      }
    }
  }
}

we frequently use a validation pattern that calls for a Collection<Validation<T>>. These validations vary from project to project, but the Validator<T> class is the same from project to project. The actual validations used varies depending on the validation requirements of the project and the type of the object that is being validated. Each instance of Validation<T> is pure business logic, and each is properly unit tested.

Determining what to put in the Collection<Validation<T>> is simply a configuration concern. This is where it is easy to use the IoC container. Since Guice is what I typically use, that's what I'll show.

Example: Say, we are dealing with Customer objects that we are importing into the system. These customers are being imported from someone else's system into ours. So, we are not sure if each customer object is valid and we only want to import the objects that are valid. There are multiple ways to bind up the collection of validations, among them are using TypeLiteral and using a marker class. For this, I will show the marker class, but I've also used TypeLiteral.

So, since I want to validate Customer, I create a class like:


public class CustomerValidations extends ArrayList<Validation<Customer>> {
 //marker class
}

Now, I'll write a marker for the validator:


public class CustomerValidator extends Validator<Customer> {
  @Inject
  public CustomerValidator(CustomerValidations validations, 
    ValidationProblemReporter reporter) {
    super(validations, reporter);
  }
}

To get Guice to inject the dependencies into the CustomerValidator, we'll need to bind CustomerValidations and ValidationProblemReporter. So, I would have a Guice Module that looks something like:


public MyModule extends AbstractModule {
  public void configure() {
    bind(ValidationProblemReporter.class).to(ConsoleReporter.class);
    bind(CustomerValidations.clas).to(CustomerValidationsProvider.class);
  }
}

We'll have to write the provider for the CustomerValidations:


public class CustomerValidationsProvider implements Provider<CustomerValidations> {
  public CustomerValidations get() {
    validations = new CustomerValidations();
    validations.add(new CustomerShouldHaveAName());
    validations.add(new CustomerShouldHaveAnEmailAddress());
    ...

    return validations;
  }
}

This cuts a very nice seam to configure which validations we want to run over our customers. I can easily write a unit test that asserts what validations we have configured. In fact, if order is important, then I can check that as well.


public class CustomerValidationsTest {
  @Test
  public void we_should_do_the_right_things_in_the_right_order() {
    CustomerValidationsProvider provider = new CustomerValidationsProvider();
    CustomerValidations validations = provider.get();
    Iterator<Validation<Customer>> iterator = validations.iterator();

    assertEquals(CustomerShouldHaveAName.class, iterator.next().getClass());
    assertEquals(CustomerShouldHaveAnEmailAddress.class, iterator.next().getClass());
    assertFalse("Should not have any more", iterator.hasNext());
  }
}

Now, we have locked down our configuration such that if we change the validations, we have to change this test. I wouldn't always lock the configuration like this, but I often do.

Guice allows you to unit test your configuration (since it's all Java). Figuring out what needs tested and what doesn't can be an art form. You'll get a better feel for it with experience.

Hudson Default Ant

2009-01-22T21:19:00.000-08:00

Most Hudson configuration is self-explanatory and easy to find in the web configuration. Many props go to the developers of Hudson because it is quite easy to setup and use. However, there are a couple of things that I've found lately that don't seem to be documented in the Hudson docs.

Configuring Ant

From the Hudson dashboard, click on
Manage Hudson -> Configure System
or you can simply navigate to
http://your-server-here/hudson/configure

Look for the section labeled "Ant" and add your Ant installations by clicking "Add" and providing a name and the absolute path for ANT_HOME. This couldn't be simpler.

Default Ant

When you are configuring a build, you can tell Hudson which Ant you want to use. You may either use one of the named Ant installations that you previously added, or Hudson gives you the option of using the "Default Ant."

For some reason, I was thinking that I had somehow set the only Ant installation that I added as the default (since it was indeed the only one). But, this was not the case, and my build failed with this console output:

FATAL: command execution failed.Maybe you need to configure the job to choose one of your Ant installations?
java.io.IOException: Cannot run program "ant" (in directory "/home/tomcat/hudson/jobs//workspace/build")

Then, I got to looking at how to set the default Ant, and I could not for the life of me find the setting anywhere. This is because, there is NO default that can be changed from within Hudson.

If you tell Hudson to use the default Ant for a build, then it will use whatever ant it finds on the PATH. Note that I did not say that Hudson will use whatever ANT_HOME points to. Hudson must be able to find the ant command on the PATH.

In our case, Hudson runs as the user 'tomcat.'

So, if I wanted to use the default Ant for a build, I would typically solve this by setting both the ANT_HOME and PATH environment variables for the tomcat user. I would set ANT_HOME to the Ant installation that I wish to use as default, and I would then add $ANT_HOME/bin to the PATH environment variable.

What I Actually Did

Since I really didn't care to go to all that trouble of setting environment variables, I just used the named Ant instance that I had already configured in Hudson. We do not have a default Ant available to Hudson, and it's not a problem.

Hudson Gets an AccessControlException when starting on Ubuntu Tomcat

2009-01-21T08:56:00.000-08:00

With fresh install of Ubuntu 8.10 I grabbed Tomcat 6 from Synaptic. Then, I dropped the hudson.war into the Tomcat webapps directory, and was greeted with an AccessControlException and a Hudson that would not start.

This is because on Ubuntu, Tomcat default installs with the Tomcat Security Manager enabled. This is probably a good thing for many installs of Tomcat, but it interferes with Hudson. When we finally found the problem, we took the lazy road and disabled the Tomcat Security. Depending on your install, this may be an unsafe decision. I would check the Tomcat documentation before doing this if your server is externally exposed. In our environment, the build server is on a completely trusted network. So, we didn't care much.

Here is the stack trace that is displayed when first trying to browse to the Hudson app:


HTTP Status 500 -

type Exception report

message

description The server encountered an internal error () that prevented it from fulfilling this request.

exception

javax.servlet.ServletException: Error instantiating servlet class org.kohsuke.stapler.Stapler
 org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
 org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
 org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
 org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
 java.lang.Thread.run(Thread.java:636)

root cause

java.lang.ExceptionInInitializerError
 org.apache.commons.beanutils.ConvertUtilsBean.(ConvertUtilsBean.java:130)
 org.kohsuke.stapler.Stapler.(Stapler.java:659)
 sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 java.lang.reflect.Constructor.newInstance(Constructor.java:532)
 java.lang.Class.newInstance0(Class.java:372)
 java.lang.Class.newInstance(Class.java:325)
 org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
 org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
 org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
 org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
 java.lang.Thread.run(Thread.java:636)

root cause

java.security.AccessControlException: access denied (java.util.PropertyPermission org.apache.commons.logging.LogFactory.HashtableImpl read)
 java.security.AccessControlContext.checkPermission(AccessControlContext.java:342)
 java.security.AccessController.checkPermission(AccessController.java:553)
 java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
 java.lang.SecurityManager.checkPropertyAccess(SecurityManager.java:1302)
 java.lang.System.getProperty(System.java:669)
 org.apache.commons.logging.LogFactory.createFactoryStore(LogFactory.java:320)
 org.apache.commons.logging.LogFactory.(LogFactory.java:1725)
 org.apache.commons.beanutils.ConvertUtilsBean.(ConvertUtilsBean.java:130)
 org.kohsuke.stapler.Stapler.(Stapler.java:659)
 sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
 sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
 sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 java.lang.reflect.Constructor.newInstance(Constructor.java:532)
 java.lang.Class.newInstance0(Class.java:372)
 java.lang.Class.newInstance(Class.java:325)
 org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
 org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845)
 org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
 org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
 java.lang.Thread.run(Thread.java:636)

note The full stack trace of the root cause is available in the Apache Tomcat/6.0.18 logs.

This was fixed by changing:

/etc/default/tomcat6

And setting the following property:

# Use the Java security manager? (yes/no, default: yes)
# WARNING: Do not disable the security manager unless you understand
# the consequences!
#TOMCAT6_SECURITY=yes
TOMCAT6_SECURITY=no

Note that we left the commented example in place for future reference. I hope this helps someone else. Mostly, I'm hoping that by writing this down, I will remember this in the future or at least be able to find the solution quicker.

Go forth and write tests...

Cool Code Snippet Tool

2009-01-14T04:36:00.000-08:00

Simple post for my own memory:

The best online code snippet posting tool that I've found is at http://pastebin.com/. It has great syntax highlighting for a variety of languages (including Groovy) and it is very easy to use.

Tests Drive Good Design

2009-01-07T13:06:00.000-08:00

Test-first development leads to better design in the production code. Specifically, you get much lower coupling (both internally and externally), and you get much higher cohesion.

For those of you unfamiliar with those two terms, Coupling is tying one class to another. For instance, if ClassA relies on ClassB to do some work in such a way that a break in ClassB causes unit tests for ClassA to break, that's coupling. We try to limit coupling so that individual classes are isolated. We will always be coupling our classes to a degre (if java.lang.String breaks, everything breaks), but we try to keep it to a minimum. We want classes with low coupling because it is easier to isolate change.

Cohesion is how well the responsibilities within a class relate to each other. Highly cohesive classes tend to be small chunks that are easy to understand because they have a single responsibility. If you are tempted to answer the question, "What does this class do?" by using the word "and" a bunch, then you have a class with low cohesion. We want classes with high cohesion because they are easier to understand and thus easier to change.

When you write good unit tests, especially when you write them first, its easy to detect classes that are NOT highly cohesive and have low coupling. Tests become much more difficult to write when you stray from sound coding practices. If you weren't writing unit tests, you might be tempted to simply "new up" a dependency. Testing drives one to inject dependencies to create better seams and better class isolation.

The bottom line is that testable code is better code. It is easier to change, easier to understand, and overall easier to support.

Private Bindings in Guice

2008-12-16T10:54:00.001-08:00

There are rare occasions when I need to bind something locally in Guice, but I don't want that binding exposed. One such time happened today. Our application uses a Configuration object to hold what we read in from a configuration file. There is plenty of configuration in that file including database connection information and email configuration for reporting errors. Various parts of the application need various parts of the configuration, but nothing really needs the whole ball of wax.

There is, however, one exception to this in our application where a Guice Provider actually does need to have the whole Configuration object. So, we need to have a singleton Configuration instance bound, but I still don't want that exposed.

Enter annotated bindings. Guice allows you to bind the same type more than once and to distinguish the different bindings by adding an annotation. The annotation gets added to the binding in the module as well as the location where the injection is to occur. So, in this case, we have a binding and Provider like so:


bind(Configuration.class).annotatedWith(DontExpose.class).toInstance(privateConfig);
bind(Foo.class).toProvider(FooProvider.class);

private static class FooProvider implements Provider {
  public FooProvider(@DontExpose Configuration config) {
    ...
  }
}

The binding is placed in the configure() method of the Guide Module, and the FooProvider is a private static within the same Guice Module class. Unless you take one extra step, however, this binding is still exposed.

Normally, my binding annotations are publicly defined within the project. Any class that Guice builds can ask for a Configuration annotated with @DontExpose. To keep that from happening, we simply define the @DontExpose binding annotation as a private element within the Guice Module. So, the final module would look something like this:


import com.google.inject.*;
import java.lang.annotation.*;
import org.apache.commons.configuration.*;

public class TestModuleShouldBeDeleted extends AbstractModule {

  private final CompositeConfiguration config;

  public TestModuleShouldBeDeleted(CompositeConfiguration config) {
    this.config = config;
  }

  @Override
  protected void configure() {
    bind(Configuration.class).annotatedWith(DontExpose.class).toInstance(config);
    bind(Foo.class).toProvider(FooProvider.class);
  }

  @Retention(RetentionPolicy.RUNTIME)
  @Target( { ElementType.FIELD, ElementType.PARAMETER })
  @BindingAnnotation
  private @interface DontExpose {
    // marker annotation
  }

  private static class FooProvider implements Provider {

    private final Configuration configuration;

    @Inject
    public FooProvider(@DontExpose
    Configuration configuration) {
      this.configuration = configuration;
    }

    @Override
    public Foo get() {
      return new Foo(configuration.getString("foo.value"));
    }
  }
}

Now, the binding to Foo is exposed (as we want it to be), but the binding to the Configuration is not. This isn't a pattern I use very often, but it was useful today.

Why I Don't Use "Given, When, Then"

2008-12-15T12:42:00.001-08:00

In Introducing BDD, Dan North states that he and Chris Matts were trying to develop a template that, "had to be loose enough that it wouldn’t feel artificial or constraining to analysts but structured enough that we could break the story into its constituent fragments and automate them." This gave birth to Given, When, Then syntax. One example that is given in the article is:

Given the account is in credit
And the card is valid
And the dispenser contains cash
When the customer requests cash
Then ensure the account is debited
And ensure cash is dispensed
And ensure the card is returned

This certainly has structure. But, I personally feel this is still a bit too artificial. Perhaps it is the large amount of content related to the context (account is in credit, the card is valid, the dispenser contains cash). I try to avoid specifying behaviors that have this many moving parts. I would prefer to see a behavior like:

The dispenser when the account is in credit should dispense cash.
The dispenser when the account is in credit should debit the account.
The dispenser when all transactions are complete should ensure the card is returned

I want to read sentences. When possible, I want to read short sentences. Given When Then generates a matrix of sentences to be parsed. GWT also saves some space in the report, but I gladly give that space back to have behavioral sentences that are easier to read quickly.

So, how do I keep the language regular and well-formed? The answer shows up more in the source code of the behvaiors than in the report. So, I might write the following behavior using EasySpec (in Groovy):


@EasySpec(interest='The dispenser')
class Dispenser_happy_path_Test extends GroovyTestCase() {

def account = new Account(balance:1000)
def dispenser = new Dispenser(available:5000)

@Context('when the account is in credit and the dispenser has cash')
public void setUp() {
  dispenser.dispense(account, 100)
}

@Behavior
void test_should_debit_the_account() {
  assertEquals(900, account.balance)
}

@Behavior
void test_should_dispense_the_requested_cash() {
  assertEquals(100, dispenser.totalDespensed)
  assertEquals(4900, dispenser.available)
}

@Behavior
void test_should_return_the_card() {
  assertTrue(dispenser.lastCardReturned)
}
}

Upon running the EasySpec report, the user will get the following behaviors:

The dispenser when the account is in credit and the dispenser has cash should debit the account

The dispenser when the account is in credit and the dispenser has cash should dispense the requested cash

The dispenser when the account is in credit and the dispenser has cash should return the card

Easy Spec actually generates reports with nice formatting like this.

Perhaps all of this is just personal preference. But, I do find it easy to go back to old specifications and understand what is going on. Language and fluency are important.

You Might Be A Behaviorist...

2008-12-15T12:31:00.000-08:00

Are you doing BDD? This is a question I've often heard at recent conferences. As far as I can tell, most people that have looked at BDD concepts are quite sure if they're doing BDD or not. Here are some sign that you might be a Behaviorist:

You talk more about executable specifications and less about "tests."
You write your specifications before you write the production code.
You place high value on natural language in your tests.
You can generate a system-wide report that shows system behaviors in natural language. Bonus points if you do this with every build.
You write your specifications or tests with exactly one context per test class.

Not everyone that is doing these things would classify their projects as using BDD. And, not everyone that says they're using BDD is applying these concepts. But, I think that in the majority of cases you will find a majority of these practices in some form or another.

If I have missed anything, Dear Reader, please let me know.

My English Teacher Would Be Proud -- Proper Language Is Still Important

2008-12-15T08:37:00.000-08:00

My high school had one English teacher that was dreaded by all, Mrs. Koch. Mrs. Koch's classes were known to be tough. Most of my friends were accustomed to getting high grades, but this didn't happen too often in Mrs. Koch's classes. Over the course of two semesters, one student got an 'A' in one semester. Mrs. Koch took for granted that we knew the basics that we were supposed to know. For written assignments, she assumed that everything would be spelled correctly and there would be zero grammatical errors. Assignments were graded for content, but grammatical errors caused sever markdowns in one's grade. Language was important.

I am thankful to Mrs. Koch for nurturing a strong sense of grammar in me. Perhaps this is what I have always liked the strict syntax of programming languages. This may also explain why I like Behavior Driven Development so much. Language was critical in Mrs. Koch's class, and language is critical to understanding business software.

BDD brings language into what I believe is its proper place -- the forefront. Language allows developers to understand the business. Language allows the development team to communicate with the project sponsors and domain experts. The more prominent, clear, and accessible our language is, the more readily we understand each other. The more accessible the language is in the code base, the easier it is to understand what we are doing and why we are doing it.

This is why I like BDD so much. When I read through specifications, I can understand what the system does. The more natural the language is, the faster I can stop thinking about syntax and start thinking about the correctness of the system. Natural language also helps to engage the non-developers on the team. While I've watched our project managers look at Java code and guess about what the system is doing, its much easier for us to have a conversation without Java language constructs getting in the way. Likewise, the less we talk about exceptions, try/catch blocks, and if-else statements, the better. Instead, we prefer discussing how the system should and should not behave under certain conditions.

Case in point: Instead of, "The protected area should thrown an exception for unauthenticated users," I would prefer to say, "The protected page should require the user to be logged in." We shouldn't have to acclimate the business types to programmer speak.

Clear language also helps us identity when the design is going astray. One simple word is often a clue to me that a class has too much responsibility. That magic word is, "and." Here's an example:

Lets assume that we're developing a console application that takes in a relatively complex configuration file. The customer has told us that, when the configuration is bad, he wants to be notified in a variety of ways. Sometimes this process will be run manually, and he would like the operator to receive immediate console output for bad configuration. Sometimes, the process is launched automatically and unattended, so he would like configuration problems to be emailed as well. For a final good measure, he has also requested that problems be logged to the logging system we have chosen for the project. We'll assume that the logging and email services live behind a nice interface that is easy to test. We might, then, get a specification that looks like this

The ConfigurationHandler, when some configuration properties are missing and logging is configured and email is configured should log an error for the missing properties and send an email for the error and write an error message to the console.

Assuming that our logging and email systems are properly testable (injected somehow), the actual calls to those services could be a pretty small footprint in the production code. However, this is too much responsibility for the ConfigurationHandler. We see it logging, sending email, printing to the console and killing the process somehow. There are lots of "ands" in the specification indicating that perhaps too much responsibility has been given to the ConfigurationHandler.

If we look at the behaviors shown, they are all about reporting the error. This is when we notice that, perhaps what we need is one more concept called the ErrorService. We can hide all the emailing and logging behind that. So, we break out a new class and a new interface and we end up with the following specifications:

The Configuration Handler, when some configuration properties are missing should report the missing properties to the ErrorService.

The ErrorService should forward errors to the log file, email, and console.

There are still some "and's" there, but the responsibilities are better broken down.

Language is critical to understanding software. BDD helps bring language into more prominence. What does the language of your specifications tell you?

Package Properly: Where Your Tests Live Is Important

2008-12-15T08:08:00.000-08:00

About nine months ago, our team decided to start using Behavior Driven Design. Rather than making big changes in the build system to bring in a BDD framework, I put together a BDD reporting framework called EasySpec that allowed us to continue to leverage JUnit. One of our goals in trying BDD was to really push the limits of natural language in testing and determine what the limits were for BDD. We ran into limits with our mocking framework, but Mockito solved those problems for us (more on that in a future post).

One thing that we found was that BDD works pretty well for all levels of testing. Many of the BDD practitioners will only use BDD for higher level integration testing. However, I've found that I really like it for unit-level testing as well. Language is important regardless of where. It is certainly nice to understand system behavior in the large, but as a developer I need to understand behavior in the small as well.

We package our unit-level tests in a test source tree that parallels the production code source tree. So, if I am spec'ing out the com.company.foo.NewFoo, then the production source lives in myProject/src/com/company/foo/NewFoo.java and the first spec will end up in myProject/test/com/company/foo/NewFoo_when_X_Test.java.

One unintended advantage of staying with JUnit and EasySpec was that our new BDD tests landed right next to the old JUnit tests. The subconscious communication that this packaging created was wonderful. It removes the step of questioning where the next test or spec should live. The next spec goes into the parallel package. This also communicates that we are going to be driving the same requirements with BDD that we drove previously using TDD methods. In other words, we aren't just writing larger integration tests with BDD. We are writing as much as possible using BDD because again, langauge is paramount to understanding the system.

How do you package your specs? And, have you pushed the limits to find out how low-level you can drive BDD concepts into your design? I love designing in the small with BDD. My production code is better, and the specification artifacts are wonderful. When supporting code writting six months ago, I find it much easier to understand the system if we have EasySpec specifications rather than JUnit tests -- regardless of the level of abstraction under test.

Publishing Build Artifacts With Hudson

2008-12-11T23:12:00.001-08:00

Tonight, I found yet another reason to love the Hudson continuous integration server. Publishing build artifacts is way easy. What's better, the latest artifacts are available under a static link. So, it's easy to set a bookmark and always have the latest output available without digging through the server.

I've setup publicly visible builds for EasySpec along with the Groovy example and Java example projects. All of these projects use EasySpec for Behavior Driven Design. A major component of BDD is having the latest behavior report available. So, I have included a build target named "report" in each of these projects. This target simply runs EasySpec to generate the behavior report into a known location in the workspace.

Let's take the Groovy example and walk through it. After every checkin, the Hudson build does

gant clean test report

This cleans the working copy, then compiles everything, runs the tests, and finally generated the EasySpec report. Relative to the working copy base, the report ends up in build_output/reports/EasySpec/index.html

To publish this report, only a couple of simple steps are required. First, go to the project configuration page for the build that you wish to publish artifacts from. In this case, that's Hudson/GroovyExample/Configure. Then, find the checkbox, "Post-build Actions / Archive the artifacts" Enter the relative path of the artifacts that you wish to publish. In this case, that's "
build_output/reports/EasySpec/index.html" Click "Save" and it's all done.

Now, everytime this project builds successfully, the latest EasySpec report is published to a constant URL. If you want, checkout the latest example EasySpec report.

I love Hudson

EasySpec Continuous Integration Server Visible

2008-11-30T22:57:00.000-08:00

I have made available a Hudson build for EasySpec. This turned out to be a fun exercise in setting up Hudson to build a GoogleCode project and a Gant project all in one. The Hudson plug-ins for GoogleCode and Gant both helped a great deal.

URL: hudson.testinfected.net

Hudson and .Net

2008-11-30T21:15:00.000-08:00

Hudson has to be the easiest CI server I've ever worked with. And, based on the number of plug-ins and the rate at which plug-ins are being developed, it must have a pretty easy plug-in model. Apparently, the gant plug-in took about an hour to write.

Configuration is very easy as well. I don't believe I've ever had to dig into the actual configuration files for different builds and tasks. The web front-end for configuration is great. I also like the ability to watch the console during a build and all of the build status tracking and archiving. There are MANY more great plug-ins available, many of which would be applicable to .Net projects as well as Java projects.

Although I'm not doing much .Net development right now, if I was, I would probably be tempted to setup a Hudson CI server to see if I liked it better than CC.Net. For those readers that are interested in seeing more about using Hudson with .Net, Redsolo has a pretty comprehensive guide to getting started.

Check it out.

GMail + Address - Why Duplicated Logic Is Still A Bad Idea

2008-08-28T20:06:00.000-07:00

If you use GMail, you probably already know that you have an infinite number of addresses with a single account. You can add periods wherever you like in the address. You can also add tags to the address using the '+' symbol. So, foobar@gmail.com, foo.bar@gmail.com, fo.obar+baz@gmail.com all go to the same place.

I like using the '+' tags when giving out my email to automated systems and signups. This makes it easy to determine if someone is handing out my address for spam when I haven't agreed to that.

Here's the duplicated logic part:

So, a while back I activated a subscription for MSDN. I used my.address+msdn@gmail.com for the email address. Today, I needeed to download something, and I went to login again, and the system is behaving like I don't remember the password. This is possible, but unlikely since the passwords that I tend to use (1) I remember, and (2) fit most all password schemes. However, I conceded that, perhaps, I don't remember the password. When I go to enter the email address for password retrieval, I get a validation error stating that the email address that I entered is malformed. Funny, MSDN didn't have any trouble sending the email to that address. I tried with the +msdn, and of course, that yielded a validation error stating that the email address was not in the system.

And, yes, I did go back to the confirmation email, and they DID send it to the ...+msdn@gmail.com address. So, that is, in fact, the address that I registered with.

It's obvious what's going on here. The registration site gleefully accepted an email address that the password retrieval site refuses to accept as a well-formed address. The logic for what constitutes an email address has been duplicated. Perhaps at some point they were the same. The registration site may have been "enhanced" to allow the '+' addresses, or perhaps the lost password site was "fixed" to only allow certain formats of email address. Regardless, it now rests as one system with different rules for what is and is not valid.

Furthermore, this leads me to suspect that the login site actually shares the same rules with the lost password site. Meaning, I was able to register with an email address that I cannot login with.

Looks like I'll have to talk with a human to get this sorted out tomorrow. Figures that I would find it thirty minutes after everyone goes home.

How Well Do You Know Your Tool?

2008-06-28T21:34:00.000-07:00

Have you ever used a great tool? I've been doing some woodworking lately. So, I've been thinking a bunch about tools. There is nothing like having a good tool when you need it. Among tradesmen, tools (and tool brands) can evoke a great deal of passion. You may have know a "DeWalt guy" or a "Matco" lover.

My grandfather was a very skilled woodworker. He took a great deal of pride in crafting fine pieces of furniture that were beautifully finished. My grandfather was a Craftsman guy. Even when offered more expensive tools, he preferred to work with Craftsman. Perhaps the source of his passion was the good service he got from the local Sears, or perhaps it was because the tools had never let him down. Regardless of why, he was passionate about his tools.

Software development tools are no different. One need look no further than the vi / emacs wars fought at countless water coolers (to this day) to see the passion that one can have in a development tool. In Java-land, you may be an Eclipse or IntelliJ devotee. In .Net, you may insist on running ReSharper or CodeRush. All of this passion is useless without one critical component...

How well do you know your IDE? When was the last time that you looked through the feature shortcuts? When was the last time that you looked through release notes for new versions? What about learning keyboard shortcuts?

I primarily learn new features two ways. I pick up tricks from my teammates when pair programming. Sometimes, I learn things completely by accident. Every once in a while, I fat-finger a keyboard shortcut, and something really cool happens. Typically, it's not a feature that I want at the time, but it's new to me. To help me remember it, I will practice it a few times, and share the new information with the rest of the team.

Take some time and read up on your IDE. Good tools are useless if you swing everything like a hammer.

Running Fitnesse Tests

2008-06-11T12:00:00.000-07:00

It is possible to execute a FitNesse page as a test, even when it is not marked as a test. This is a good thing. Say that you have a page that resides at:

http://localhost:8181/MySuite.MyTest

You can simply execute that test by appending "?test" to the end of the URL. Likewise, you can execute the page as a suite by placing "?suite" at the end of the URL.

In our project, we have some pages that are common to all tests. In order to prevent those pages being executed as tests, we changed the page property to indicate that they are not tests. However, it is occasionally useful to execute those pages by themselves for debugging purposes. Rather than going through the annoyance of setting the "Test" property and hoping that I remember to clear it, I can just append the magic text to the end of the URL, and I'm off to the races.

Agile Austin Open Space

2008-05-30T16:44:00.000-07:00

The Agile Austin Open Space kicks off this evening with agenda and topic setting. You can find the proceedings documented on the wiki at: openspace.agileaustin.org

I will be blogging about proceedings as I see things interesting. Be sure to watch the wiki.

Why Behavior Driven Development?

2008-05-28T20:41:00.000-07:00

Two years ago, I became completely test-infected. I hate writing implementation code without writing the test first. Then, about six months ago, I was introduced to Behavior Driven Development (BDD). I liked what I saw, but I really didn't see any tools that I wanted to bring into our build system. The last thing that I wanted to introduce to the company was another test framework. JUnit was meeting our needs fairly well, and we were already using FitNesse on our team whereas the rest of the company was not. We didn't want to add another tool on top of that.

Then, a few months ago, I saw Scott Bellware give a talk on BDD and saw how he simply did BDD within a normal unit-testing framework and used .Net attributes to markup the tests with the BDD language. I liked what I saw. That night, I started a similar tool for JUnit called EasySpec. The tool still has some kinks to work out, but BDD has definitely brought some interesting insights into how we design our tests.

So, why BDD? At first, it was simply a trial of a style that seemed to do a good job of pulling out the Ubiquitous Language. Now that we have been using the techniques for about three months, I must say that I really like using BDD for creating software -- especially around the Domain Model.

BDD cleans up the language and gets the developers talking more about behaviors and less about implementation. Where, in the past, I might have been tempted to write a test with a method name like, "the_service_should_throw_an_exception_if_the_user_is_not_authenticated," I would now write that same test with a name like, "the_service_should_require_authenticated_users." Internally, the test would still be implemented in the same fashion, with probably the same code. However, language is important. It's important for the developers to think in the domain rather than hiding in the implementation layer. If I'm interested in the details of how the service requires authenticated users, then I can look at the details of the test (which should still be cleanly written) and see that in fact, the service will throw an exception if it somehow is handed an unauthenticated user.

This is merely one example. Keep a watch here for more information about BDD and why I'm hooked. Also, I should be putting some polish into EasySpec in the next week or two so that it's more user-friendly. If you're already using JUnit, and you want to try out BDD, take a look at EasySpec.

EasySpec in the works

2008-03-14T21:55:00.000-07:00

I have started a new project named EasySpec for doing Behavior Driven Development in Java and Groovy. There is plenty of functionality that I want to add soon, but the core of it is available (as a .jar). The project page on GoogleCode can be found at http://code.google.com/p/easyspec/.

Our team has been using EasySpec for guiding our behavioral specifications for the last three months. I am hooked. If you want specific examples, leave some feedback here. I should be finishing up the current feature development within the next day or so. Then, I will be finishing some examples to be posted by the end of next week.

Create a Guice Injector Using Multiple Modules

2008-03-14T10:07:00.001-07:00

This is a very short note, but I spent too much time on Google looking for this answer and I wanted to provide a concise bit of information about it. It has recently become necessary for us to separate our Guice configuration into multiple Guice modules. We tend to have some dependencies that are project specific and others that typically remain constant from one project to another. I didn't see mention of this in the Guice guide. So, here is the information:

Guice.createInjector() can take a variable number of Modules. So, it is trivial to do this:

Guice.createInjector(myProjectDependencies, myDatabaseDependencies) and so on.

This will really help to prevent duplicating binding logic from one project to the next. We are separating our data-tier module out from project-specific bindings.

Again, all of this is trivial, but since I didn't readily find the answer on Google earlier, I wanted to put it out.

Another interesting note is that it is possible to bind to classes in module A that need bindings from module B while at the same time bind to classes in module B that need bindings from module A. Very slick.

How To Quickly Frustrate Future Developers

2008-02-08T09:45:00.000-08:00

Simply put, if you want to frustrate your teammates, let your abstractions leak.

Have a production implementation of an interface with stubbed calls? How about a subclass that neuters parent-class functionality? If you do, you may be well on your way to setting a trap for future developers (quite possibly your future-self).

Interfaces
If you really don't need all the methods on an interface, then the interface is too big and should be broken out. Here's a contrived example. Consider what an IDaddy interface might look like:


interface IDaddy {
  public void changeDiaper(Baby baby);
  public void procreate(IMommy mommy);
  //More methods, but significantly less than the IMommy interface.
}

This interface had better have a singleton production interface. Otherwise, other implementations of IDaddy that implement the procreate(IMommy) will have some serious 'splaining to do! (IMommy better be a singleton as well, or the IDaddy is in big trouble...).

Anyway, there are certainly uses for having someone other than Daddy change the baby diaper. Perhaps a better set of interfaces would be:


interface IBabySitter {
  public void changeDiaper(Baby baby);
}

interface IDaddy extends IBabySitter {
  public void procreate(IMommy mommy);
}

Now we can have several implementations that can change the baby diaper without creating family strife!

Subclasses
Just ran into this class today:


public class UnknownColumnNameException extends RuntimeException {

  private static final long serialVersionUID = 1L;

  String strColumnName;

  public UnknownColumnNameException(String colName) {
    strColumnName = colName;
  }

  public String toString() {
    return super.toString() + " ColumnName = " + strColumnName;
  }

  public void printStackTrace() {
    System.err.println(" ColumnName = " + strColumnName);
    super.printStackTrace();
  }

  public String getColumnName() {
    return strColumnName;
  }

For those of you not completely familiar with Java's exceptions, you may not notice what is missing. In the top level processing, we have a generic, last-ditch catch of all Throwable so that we can dump log files, etc. This exception has not set any message. So, when I do an ex.getMessage() in the top-level catch, all I get is null. Thanks for nuthin'.

The user has to know about this specific exception type in order to get the useful information back out of it. Bad, Bad, Bad! If this pattern was extended, then we'd have to put a catch for each type of exception that just might happen, and pull the specialized information out of each one. Forget it!

The fix? Simply set the message in the subclass. In this case, this can be done by leaning on the superclass constructor as follows:


public class UnknownColumnNameException extends RuntimeException {
  ...
  public UnknownColumnNameException(String colName) {
    super("Could not find column with name '" + colName + "'.");
    strColumnName = colName;
  }

Simple fix. Great improvement in usability. Perhaps next time, I won't have to resort to the debugger to know that the input file has a problem.

What kind of abstraction leaks have you found?

How Can a Simple Code Template Change Make Life Better?

2008-02-05T10:05:00.000-08:00

Ever felt like making a small change has sent you down a rabbit hole? I sure have. Consider the following classes:


public interface NotificationService {
  void sendNotification(String user);
}

public class Unit {
  private NotificationService notification;

  public Unit(NotificationService notification) {
    this.notification = notification;
  }

  public void doSomething(String username) {
    notification.sendNotification(username);
  }
}

You might write a test to ensure that Unit.doSomething() passes off the username to the NotificationService.sendNotification(). This would be a very simple mock test.

Now, let's assume that everything shown so far is already under test, 100% coverage. Requirements have changed, and now when we doSomething(), we should check for pending notifications for that username first.

The first change to make would be adding a method to the NotificationService interface:


public interface NotificationService {
  void sendNotification(String user);
  Notifications retrievePendingNotifications(String user);
}

Now, we can write a test for the Unit class, using a mock of NotificationService to verify that doSomething() will check for the pending notificiations. Doing Test-Driven Design, we want to make sure that we are focusing on changing one class at a time. However, now that we have added retrievePendingNotifications() to the interface without actually implementing that method on the implementing classes, we will have a compile error.

One choice for getting around this would be to go down the rabbit trail, writing tests for the implementing classes and actually implementing the new method. Personally, I don't like to do this because it changes my focus. I would rather first ensure that the caller is correct before worrying about the actual implementation of the interface.

Most modern IDE's will offer a quick-fix to stub out the implementation of the interface so that things will compile. The default behavior for this default implementation is typically to return the simplest thing possible. If the function is void, then the stubbed method does nothing. If the function returns a primitive, say int, then the IDE will put in something like return 0; to make things compile.

This kind of default stub has already worried me that I will forget to actually do the implementation. In fact, I have done just that before, sometimes not finding the hole until a day or two later. At that point, figuring things out sometimes involves going to the debugger to figure out why I'm getting a NullPointerException.

Enter code templates. The default implementation can be modified in most IDE's. Here is a sample of how I changed my code template to prevent this problem in the future:


  public Notifications retrievePendingNotifications(String user) {
    throw new NotImplementedException(
      "NotificationServiceImpl.retrievePendingNotifications() not yet implemented.");
  }

Now, I don't have to try and keep that little piece of information in my head. I can rest easy that, if I forget to implement something, it will still fail (hard) during integration testing. Now, I will know the direct cause of the problem immediately.

It's amazing to me how this simple change has made me rest so much easier.

Go forth and write tests!

DRY Groovy, How To Get Groovy To Import A Class Into a Script

2008-01-18T23:26:00.000-08:00

UPDATE: Read to the bottom to see another way to tackle this problem

Each time you repeat yourself in code, you may as well leave a bear trap by your desk. In fact, the bear trap is probably safer for me. Whenever I see repeated code, I want to poke my eyes out. I do my best to keep my code dry whenever reasonable.

So, when I started writing Groovy scripts, it became obvious pretty quickly that I had some utility classes waiting to break out. The only problem was, I couldn't find the technique for importing a Groovy class from another file into the current script. Thanks go to Peter Niederwieser for the solution.

Here's the setup:

Two Groovy files:
c:\tools\groovy\myscript.groovy
c:\tools\groovy\MyClass.groovy

The content of MyClass.groovy:

class MyClass {
  def howdy() {
    println 'Howdy'
  }
}

The content of myscript.groovy:

new MyClass().howdy()

Super simple. However, no matter how I tried to run myscript, I got this error message:

org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed,
c:\tools\groovy\myscript.groovy: 1: unable to resolve class MyClass

What gives? The files were right next to each other, but stupid Groovy couldn't find them. That's when Peter reminded me that groovy will look in the classpath to resolve classes.

There are two ways (that I know of) to tell Groovy what your classpath is. You can either indicate it on the command line as in:

groovy -cp c:\tools\groovy myscript.groovy

Or, you can set the CLASSPATH environment variable to include the path where the collaborating class (in this case, MyClass.groovy) lives.

Using the classpath, you don't even have to keep your script and its dependencies in the same directory. I simply set my CLASSPATH, and now I'm off to the races. Now, I keep all my scripts in c:\tools\groovy (which is on my PATH), and my classes in c:\tools\groovy\classes (which is on my CLASSPATH).

WARNING: For all of you Windows users out there, the name of the Groovy file IS CASE SENSITIVE! So, if you want Groovy to find class MyClass, it had better be in something like, %CLASSPATH%\MyClass.groovy. %CLASSPATH%\myclass.groovy did NOT work for me. This would make complete sense to me if I were in a Unix environment. However, I am used to my Windows machines being mostly case insensitive. This is a bit odd, but understandable I guess.

UPDATE: Jochen Theodorou has pointed me in the right direction for another solution that I like better. You don't have to modify the classpath to cause groovy to find the classes that you are importing. Instead, you can add load information to your %GROOVY_HOME%\conf\groovy-starter.conf file. Mine now has these extra lines:

# load classes for local scripts
load c:/tools/groovy/classes

Now, I don't have to keep the CLASSPATH environment variable set and worry about how that interacts with Java.

There you have it. Now, you can keep your scripts dry.

Mocking Groovy Objects with EasyMock in Java

2008-01-14T06:53:00.001-08:00

I mentioned before that I needed to do some unit testing of a class that I was targeting in Groovy with come unit tests in Java. In Java, I am using EasyMock to mock out the collaborators. I am dealing with one collaborator, an interface, that looks like this (Groovy):


interface FileSystem {
    ...
    def uploadFile(inputStream, destinationPath)
    ...
}

For the purposes of this unit test, I didn't care what got returned, so I setup the expectation like this (Java):


desintationFileSystem.uploadFile(streamForFile1, "someDir\\someOtherDir\\file1.jpg");

Running the test, I was greeted with this message:


java.lang.IllegalStateException: missing behavior definition 
  for the preceeding method call 
  uploadFile(EasyMock for class java.io.FileInputStream,
    "someDir\someOtherDir\file1.jpg")
    at org.easymock.internal.MockInvocationHandler.invoke(MockInvocationHandler.java:27)
...

That's when I remembered something fundamental to groovy... the 'def' type means variable return type. For Java, that translates into Object. To make the test run, I either needed to explicitly change the return type on the interface to be void, or simply setup the EasyMock expectation to return a value. Since I didn't want to change the interface, I chose to specify the return value in the expectation.

How to Cure a Groovy Headache with Java

2008-01-13T18:49:00.000-08:00

There was a time during my college years when I was a full-on caffeine addict. I remember once during finals consuming around 10 cans of Dr. Pepper per day. When I decided that I needed to come off the caffeine, I had to use some java (coffee) along the way to avoid the nasty headaches.

Fast forward a few years, and I've once again use some Java to cure a headache. However, today's headache was caused by a mixture of concrete classes and Groovy's seeming inability to mock concrete classes. I wish I knew the Groovy life cycle a bit better to explain exactly why it is that I couldn't mock out java.io.FileInputStream. Suffice to say, Groovy didn't let me substitute in a closure, I didn't want to use mockFor because there was enough else going on. Additionally, Groovy didn't want to cooperate with the EasyMock classextension for reasons I never could quite figure out.

In comes the Java. Since Java and Groovy compile down to the same byte code, testing Groovy with Java is pretty easy. The final solution that I came up with was writing the implementation in Groovy like I wanted to, and writing the test in Java. I simply used org.easymock.classextension.EasyMock to do the mocking, and away we went. This was a nice proof of Java and Groovy living right next to each other and working together. One of the nice things about having the ability to do the test in Java was proving that, indeed, I had all of the project dependencies that I needed and Groovy just did not like mocking out the class.

Watch here soon, and I am going to post a cool little tool that I am working on for spiking the project structure for a setup like this. It's much more stripped down from what Grails will give you. But, if your looking for directory structure and a simple build.gant, then this may be something to look at.

Now, where's my decaf coffee?

Why Do You Use TDD?

2008-01-11T14:05:00.000-08:00

After about a year and a half of writing tests before implementation, I'm not sure I will ever go back. Most people call this "Test-Driven Development." However, given the benefits that come from working this way, I prefer the term, "Test-Driven Design."

I use TDD for three reasons - (1) Test-Driven Design forces more loosely coupled code which is much more malleable, (2) I can detect code smells much faster when classes become difficult to test, and (3) it is easier to know when I'm done writing code.

The tests are a nice bonus product of designing code this way, but they are, in fact, not as important to me as the loose coupling and general good design that comes out the other end. When writing tests becomes too difficult, noisy, or lengthy, then something is wrong with the design. Since tests are in place, refactoring to a better design is easier and generally faster. So, this too aids in improving the design of the implementation.

Do the tests get in the way sometimes? Yes. However, this is often a test smell. Perhaps the tests have too much intimate knowledge of the implementation.

If you have not tried writing tests first, I suggest giving it a go on a simple project. Better yet, find someone that is already experienced in TDD and do some pair programming.

Now, go forth and write tests...

When Subversion Goes Crazy

2008-01-08T16:24:00.001-08:00

Recently, in the midst of a bunch of subversion client updates, some client decided that I was working with ASP.Net files. So, the "SVN_ASP_DOT_NET_HACK" environment variable got set. This causes subversion's directories to be named "_svn" rather than ".svn." This would be great if I needed the feature to prevent ASP.Net from getting confused. However, it turned out to be a royal pain in the rear, and a big confusion for Eclipse. Eclipse does NOT ignore "_svn" files correctly.

It was quite a shock to suddenly see a bunch of _svn folders on one machine, but not another when working with the same repository.

Alt.Net Mailing List - The Hidden Benefits

2007-11-02T20:29:00.000-07:00

Since the Alt.Net mailing list saw it's first post on October 8, 2007, the list has seen an average of 87 posts per day. The content is wonderful (now that we aren't arguing about the name so much).
This high volume has also done wonders for my ability to scan and speed read. This is a skill that I had during my schooling but seemed to have lost. Now that I have been following this mailing list, I have seen much more zero-bounce in my blog reader - even though I have more feeds coming in.

Now, I can finally keep up with the volume of content coming from Ayende's blog.

Am I Doing Scrum? - Nokia's Benchmark for Scrum Adoption

2007-10-31T09:17:00.000-07:00

Dr. Jeff Sutherland, and Agile Manifesto signatory, has posted an excellent interview, "Scrum and Not-Scrum". As part of this interview, he advocates eight questions that Nokia uses to determine if their teams have adopted Scrum. Jeff presents this as a boolean test. If the team can answer "yes" to all eight of these questions, they are doing Scrum. If any question gets a "no," then they have not fully adopted Scrum. Here are the questions:

First Tier:

Are you doing iterative development?

Do you have a fixed iterations lasting less than six weeks?

At the end of the iteration, do you have working software?
Can the team effectively start work on an iteration without a detailed specification?
Is testing part of the increment?

Second Tier:

Do you have a product owner?
Does the product owner have a prioritized, estimated product backlog?
When the team is developing, do they have a burndown chart?

Can you calculate the team's velocity?

Is the team self-organizing?

In other words, does the team choose, assign, and map the fastest possible way to deliver the work?
The project manager cannot interfere with the team during an iteration.

I highly recommend watching this interview. It is only about 20 minutes long, and it is packed with good information including a summary of Google's boiled frog adoption of Scrum on the AdWords project.

Jeff also reminds us that Scrum will not solve your organizational problems, but it will make them painfully obvious.

Programmers Anonymous: Confessions of a Terrible Software Developer

2007-10-30T06:42:00.001-07:00

Marc has posted his "Confessions of a Terrible Programmer." The overriding tone of the post can be summed up in the following pseudo-Zen quotes:

You will never become a Great Programmer until you acknowledge that you will always be a Terrible Programmer.

and,

You will remain a Great Programmer for only as long as you acknowledge that you are still a Terrible Programmer.

Marc does a very good job of stating how he overcomes his "terribleness" to provide working software. According to Marc, his solutions are doing a good job of hiding the fact that he is a terrible developer. However, I believe that agile practices present different solutions to these problems. In broad terms, Marc favors failing fast where I favor multiple levels of testing, Test-Driven Design, and the fast feedback loops provided by good test coverage coupled with Continuous Integration.

To address more specifics, I have provided a summary of Marc's solutions along with where I think agile solves these in a different way.

Marc says he favors strong typing to prevent problems. Having done most of my work in static languages (Java, C#), and some in dynamic language (Groovy), at this point I prefer solid unit test coverage (100% with excuses). Test-first design helps with this too. Once I have good test coverage, those tests are unearthing the same problems that the compiler would. With the dynamic languages, I find the same errors a bit later, but I get the benefit of code that I find to be much easier to read.

Marc favors programming assertions. Marc is a paranoid programmer. He will assert that something is not null even when he controls both sides of the interface - just in case he might change something later. I personally find that assertions and paranoid programming in general fall under the related headings of YAGNI and nosiy code. Instead, I prefer solid unit testing and a tester that knows how to unearth the edge cases. Write unit tests that assert that the service in question does not return null to box in the behavior.

Marc says he will, "ruthlessly try to break [his] own code." It appears that Marc is trying to accomplish through developer testing what should be done by an actual tester. While I agree that developers should be generating tests that give great code coverage, it is a waste of time to make them switch hats and become a tester for their own code. Hire a tester. They think differently from developers. Their concerns are different.

Marc favors code reviews. I favor pair programming. Both provide feedback, but I want my feedback while I'm "in the zone." I want my feedback immediately. I don't want you to sit back and wait for me to find my own bugs. If you see something, tell me. Tell me as soon as it looks like I've finished typing or as soon as it looks like I'm looking for the bug. This way, I can fix the problem without having to make the context switch to come back to it later. Plus, the quality of the review is better since the other developer should be equally engaged in the generation of the code while it is being generated.

To be honest, our team is not able to follow all of these guidelines at the moment. Our biggest problem is not having a dedicated software tester embedded with the team. We ARE having to generate the types of tests that a dedicated tester should be doing. And, we are missing some things that a tester would catch much earlier in the development process. I feel that this missing component of our team IS hurting our velocity.

Am I a terrible programmer? Yes. If you find me stating otherwise, please redirect me to some of my own code - something that I wrote yesterday should do just fine.

What are you doing to hide the fact that you're a terrible developer? I would love to hear.

How To Pass Command Arguments With a File Type

2007-10-26T06:54:00.000-07:00

UPDATE: This issue appears to be fixed with the Groovy 1.5 Windows install package. However, this is still good general information to know about passing command arguments with file associations in Windows.

I just upgraded my groovy install to the latest RC for 1.1, and it quit recognizing command arguments. I tried debugging all kinds of older scripts that I knew worked, and none of them were working anymore. That's when Steve reminded me that the Groovy install messes up the Windows file extension association. So, it installed the .groovy file association like this:

"C:\groovy\bin\groovy.exe" "%1"

And it needed to be changed to this:

"C:\groovy\bin\groovy.exe" "%1" %*

This will allow the other command arguments to be passed when the groovy script is kicked off.

To change the file association (in XP),

* Open My Computer
* Tools -> Folder Options...
* Click the "File Types" tab
* Find the file type you want to change, ".groovy" in this case, and click it
* Click the "Advanced" button
* Click the "open" action
* Click the "Edit..." button
* Edit the content of the text box under, "Application used to perform action:"
* OK / Close your way out of the dialogs.

Obviously, this will work for other file associations. This method, while it forces you through a few windows, allows you to avoid mucking with the registry directly.

Don't Get Fooled

2007-10-22T15:05:00.000-07:00

Junk is junk. Whether it comes in your (snail) mailbox or your Inbox, it's junk.

Scott has a post asking how to teach common sense when here. Some will learn, some won't.

People that fall for scams fall for them whether they come by snail mail, telephone, or email Email is the easiest to perpetrate. Therefore, more people are falling for email scams these days.

The unfortunate thing is that I haven't found a way to foist pain back onto those that are populating my Inbox with crap. Actually, my filters are pretty good these days, so I don't see most of it.

With telephone scams, my game is (when I have the spare time) to keep them on the phone for as long as possible. I once kept a scammer on the phone for two hours while he kept trying different ways to get me to tell him my bank account and routing number. At least for those two hours, I knew that THAT guy was not scamming someone's grandmother.

Why Are You Asking Me This Question?

2007-10-10T05:56:00.000-07:00

Any developer that's been around this industry for any length of time has found himself in a conversation like this one:

Manager: Hey, Mr. Developer, TheBusiness has decided that we need to develop a product to do XYZ. How long will that take?
Developer: Hrm... I'm not sure. What are the details of XYZ?
Mgr: The details aren't important. I just need an estimate
Dev: Well... something like 8 weeks.
Mgr: Okay, well how much longer until you finish the thing you're working on?
Dev: Around 4 weeks
Mgr: Okay. Thanks.

[10 weeks later]

Mgr: So, Dev, I'm looking forward to having this XYZ product. We've already sold it to 50 customers and they're excited to be getting it in two weeks.
Dev: WHAT?!?!?!

This is not a fun series of conversations. The breakdowns in communication should be obvious. The manager (unknowingly) expected way too much precision from the developer's estimate, and the developer gave it without nearly enough qualifying statements pointing out that it's a WAG.

So, how can this be fixed? Many developers that I know say, just don't provide the estimate. While most of us could get away with that, it doesn't necessarily help the conversation. I prefer to answer with, "Why are you asking me this question?" This is a question that I learned to ask by watching a former team lead, Glenn Burnside. Whenever a salesperson or manager would ask the team a question like, "How difficult would it be to...," Glenn's response was always the same - he would ask this question. This always resulted in a conversation that fleshed out a more detailed question (or questions) and much better, more precise answers.

The hardest part of software development is interacting with those objects that have a pulse - not those that have a system clock.

altnetconf - Cool Tools Don't Make Cool Software

2007-10-07T21:16:00.000-07:00

I'm pretty sure that Jimmy Hendrix could make awesome music with a cheap guitar. Likewise, I could drop $5000 on a beautiful vintage guitar and I still won't be going on tour with anyone. The artist makes the tool work. While good tools make the artist's life a bit easier, they don't make the artist.

Likewise, it is perfectly possible to write clear, maintainable software without the use of things like inversion-of-control containers and mock frameworks. This weekend at the Alt.Net conference, I spoke with some very smart developers that don't use these tools that I take for granted. Tools that I even view as a necessary item. One developer that I spoke with stated that he has yet to find a need to use a mocking framework. Instead, he prefers the Testable Object pattern. I was completely taken aback until I grokked what his explanation. While I'm not going to drop my use of easymock, I see that this is certainly a valid way to do things.

I had the opportunity to speak with another developer this weekend - a brilliant developer and the second person ever added to my feed list. When the table at lunch started talking about IoC containers, he said that he's never seen the need for one. I found this to be very surprising. Once a couple of us explained why we like and use tools like StructureMap and Guice, he quickly grokked what was going on, and I think he could see why some find them to be useful tools to have. However, it also became clear that he had found other ways around the pain of supplying dependencies when using Dependency Injection.

All of this is to say that I was reminded that I don't have to pull in every tool under the sun. It's good to keep my head up and take a look at what others are doing to alleviate problems. However, there are also other ways around problems that may not involve pulling in yet one more tool.

It's not the tools that make the software good. It's the developers that apply sound judgement and experience - regardless of what tools they have.

altnetconf - Random Thoughts on Fishbowl

2007-10-06T12:32:00.000-07:00

Some of the sessions are using the fishbowl format. This is a really fun format that lets just about anyone that wants it the opportunity to contribute content to the conversation. However, this did not work very well during the BDD Discussion most likely because code samples were being periodically presented on the projector. This was proof positive that if your turn on a video source, the entire audience will focus on it. In this case, chairs were setup for the fishbowl, but the fishbowl rules were not followed by the audience. Because the group was focused on the screen rather than the chairs and the people in them, the conversation was not controlled.

Either present video or do the fishbowl, but it seems you cannot do both at the same time

altnetconf - Behavior Driven Design

2007-10-06T09:28:00.000-07:00

This post is separated into summary and thoughts.

Summary

This thing called "Behavior Driven Design" (BDD) doesn't seem to have a formalized definition. Not everyone in attendance could agree on what "it" is. However, the most clear definition presented involves several components. Scott Bellware asserted that BDD = UserStories + TDD + UbiquitousLanguage + Solubility.

Some constraints on the above components should be explained. User stories must be well-formed. So, the idea is that during a conversation that the business analyst and the developer would work together to produce a story of the form "As a... I want to... So that..." The assumption is made that the TDD being used is driving design at a granular level with only one assertion per test. To extend Scott's definition of Solubility linked to above, another term "grokability" was proposed by Scott Hanselman.

The Behavior Driven Design (BDD) session began with many questions, asked many more, and perhaps answered a few things. Bellware started by saying that BDD is not about testing. He later stated that BDD provides better tests. So, to summarize, BDD is not about testing... except when it is. So, that make that about as clear as mud.

Much of the discussion centered on improving the conversation. More specifically, the conversation between the developer and the business analyst was discussed.

One criticism presented is that BDD is using programming languages to discuss things with the business analyst. The concern was that we would be asking business analysts to write specifications including the markup. This bred a great deal of consternation.

This critique was perhaps diffused later when the suggestion was made that the business analyst would sit down with the programmer, and the two would discuss the user story and the specifications. During that discussion, the developer would transcribe the conversation into the story markup used by the spec tool (RSpec, NBehave...). Another possibility presented was that the conversation could be initially captured onto a story card and then transcribed to the tool by the developer at a later time.

There was the assertion made that BDD provides or formalizes context for conversations with the business analyst and context for the developer to write the implementation.

Scott Hanselman says, "This is like NUnit that generates prose." There seems to be a bit of buy-in for this. Perhaps C# doesn't lend itself to the readability of the spec implementation. The business owner writes this through the ears of the developer that is sitting next to him.

Part of BDD is generating a specification document directly from the tests. This allows the tests and the information being passed back to the business analyst to stay in sync better. This is NOT to replace verbal communication, but again to provide a talking point to augment the conversation.

Thoughts

It seemed as though the thoughts around BDD have application in many parts of the development life-cycle. BDD practices are useful for clarifying the discussions that should be taking place during the entire process. The initial definition of user stories is helped by these practices. During development, BDD practices help developers see the bigger picture. Finally, and importantly, the executable specifications serve as a note to the future self. In other words, when you come back to the code, it is easier to understand why the test was written in the first place.

Much of the confusion came about because these thoughts are useful in so many different places. It seemed that participants saw the potential to have certain pains alleviated, then latched onto that particular portion of usefulness. BDD is aspect-oriented. It is a cross-cutting concern and does not simply fit into a single portion of the development process. Wherever there is conversation in the development process, formalizing that conversation helps to remove ambiguity.

Perhaps this is more useful when you MUST generate documentation. Not everyone needs to have everything generated in paper form. For some business, people, they feel better seeing the specifications generated as either a sheet of paper or a web site. Even in situations where this documentation must be generated, this documentation is not set in stone.

I'm pretty convinced that we don't need a separate tool to do effective Behavior Driven Design. We need to get much better at language - both natural language and expressing natural language with programming languages. As if the natural language wasn't ambiguous enough, we are forced to complicate it by writing something that the parser can understand.

The conversation about this is still in process. I'm sure that I don't know everything about this. I hope to continue to look in this area and find ways to write better software with less pain.

altnetconf - Alt.Net First Impressions

2007-10-05T22:18:00.000-07:00

I'm not sure how much I will find myself around the computer this weekend, but I thought I would post my impressions of the ALT.Net conference as we go along. The comments during the opening remarks and fishbowl seemed to center around a few core concepts:

Though perceptions might be otherwise, nobody expressed total contempt or hatred of Microsoft.

Everyone wants to write better software.

Writing better software probably means using tools that weren't developed in Redmond.

The overriding of "better software" seems to be maintainability.

Drag-and-drop is still the whipping boy of this crowd.

Alt.Net IS alternative because most .Net developers seem to use whatever tools Microsoft puts out (and MSDN talks about). Conference attendees are much more likely to use tools that are alternatives to simply the set put out by Microsoft.

I'm looking forward to hearing more opinions and thoughts as we go along. I'm not sure how much will be decided. Many seem to want to come to a consensus, but everyone in attendance is so passionate that it may not happen. We'll see. At least we're trying to figure out what is going on and how we can deliver better software for all involved.

Don't Use Mocks...

2007-10-03T08:59:00.000-07:00

...when you aren't really interested in testing the interactions. This is related to my previous post regarding mocks and stubs. If leaving off the verification of mocks wouldn't change the nature of what you are testing, then you aren't writing an interaction-based test. Therefore, the mock dependency probably creates more noise than simply using a simple stub. If your dependency is not behind an interface, you can in most cases still create a stub using subclass and override.

While writing:


Dependency dependency = createMock(Dependency.class);
expect((Foo)dependency.bar(anyObject())).andReturn(somethingValid);
ThingToTest target = new ThingToTest(dependency);

isn't too bad. It still causes more noise than:


ThingToTest target = new ThingToTest(new DependencyStub());

Most of the time, I see that stub and grok the fact that in the context of this test, I really don't care what the Class under test does with that dependency.

Write better tests using a combination of mocks and stubs.

2007-09-29T19:19:00.000-07:00

I love using EasyMock. It's just plain, well, easy to use most of the time. Most of the time, it doesn't get in my way. However, there are certain times when I will avoid using a mock object in a test. This is best show by example.

As background, remember that mocks are not stubs and stubs are not mocks. You can use a mocking framework (like easymock) to create stubs, and you can even create mocks by hand (with a good deal of pain). Roy Osherove has done a great job of describing the differences between mocks and stubs. You should check out Roy's explanation. This is a different explanation from what I've seen before. If you want a good, detailed description of the differences, Martin Fowler has provided an in-depth comparison between the two including code samples. You should take a look at Fowler's explanation to understand the terminology.

I won't rehash the explanations. What I will say is that I've found value in doing both interaction-based testing (with mocks) and state-based testing (with stubs). When your classes are well decomposed and decoupled, mock testing makes more sense in most cases. However, when I'm interested in how a particular piece of code affects state on objects that pass through it, I will use a stub.

Here's the promised example. Supposed a I have a class, we'll call Processor that interacts with a dependency that sits behind and interface called EmailService. I'm interested in testing that Processor.emailManagers("we have a problem") can create an instance of Email with the correct properties set and hand that off to the EmailService. Looking at the test first, we have:
@Test public void myTest() { EmailServiceStub serviceStub = new EmailServiceStub(); Processor processor = new Processor(serviceStub); processor.emailManagers("This should be working"); email = serviceStub.getLastSentEmail(); assertNotNull(email); assertEquals("This should be working", email.getMessage()); assertEquals("managers@FooInc.com", email.getTo()); assertEquals("An Automated Message from 'The System'", email.getSubject()); assertEquals("TheSystem@FooInc.com", email.getFrom()); }
Obviously, we'll need something to stand in the place of the EmailService so that we don't actually send an email in the course of running this unit test. The stand-in for this test is done by a stub like this:
public class EmailServiceStub implements EmailService { Email lastSentEmail = null; public void send(Email email) { this.lastSentEmail = email; } public Email getLastSentEmail() { return this.lastSentEmail; } }
The actual implementation code for Processor then might look like this:
public class Processor { EmailService emailService; public Processor (EmailService emailService) { this.emailService = emailService} public emailManagers(String message) { Email email = new Email(); email.setBody(message); email.setSubject("An Automated Message from 'The System'"); email.setTo("managers@FooInc.com"); email.setFrom("TheSystem@FooInc.com"); emailService.send(email); } }
To be fair, this kind of testing is possible with EasyMock as well. You CAN check the properties of the object that are passed to send() using EasyMock. However, I find it incredibly painful to do so. What's worse, it makes the test convoluted to read. EasyMock would have you define your own implementation of IArgumentMatcher as indicated here. (search for "Defining own Argument Matchers"). Blech! We've done this before, and it seems to make the tests much more difficult to grok when I come back to them.

There are plenty of good examples of when you would want to use mocks over stubs. The Fowler post linked to at the top is a good start. I still use mocks for most of my testing, but in this instance, it's easier to use a stub than battle EasyMock.

Convention Over Configuration is Nice... Except When It Isn't

2007-09-26T08:48:00.000-07:00

Convention over configuration should lead to predictability. This breaks down when the default behavior of a system is unexpected. Take Guice for example. Guice will automatically bind to a class if the only constructor is a zero-argument constructor. This will happen even if the constructor is private.

This is not the path of least surprise when I forget to configure the behavior. I don't mind there being default behavior, I would just like to be able to turn it off. Moreover, I would like the opportunity to turn certain features off.

Private should mean private at least.

Warning: Frustrating Toolsets Ahead

2007-09-11T06:23:00.000-07:00

The opinions expressed here are in the context of working on relatively short-term projects against a legacy code base. If this is not your situation, adjust or ignore as appropriate.

I love tools. I'm a huge believer in using the right tool for the job. Perhaps this is because I can use that crutch as a good excuse to hit the local big orange box when I start a new project. Regardless, I've found that tools that some have labeled "frustrating" have been downright helpful and productive in our projects.

Last week, Scott pointed out that perhaps user stories don't make good test artifacts. I'm inclined to agree. Jeremy has also reminded us in the value of testing small before testing big here. While I see the value of this, I don't agree that the small (unit) tests all need to be written before the larger (integration) tests.

To provide a bit of background, my team largely works on writing Java applications that import data from a variety of sources into the existing system at DrillingInfo. To be clear, we don't work much with the web front-end. Our main job is bringing new data sources on-line and making the data make sense within our existing domain model. Therefore, the internal customers are only tangentially concerned with the appearance of our final product. They are really more concerned that data makes it into the system in a way that fits the existing system. They might even express their desires in terms of how new data should appear on the web site. Those requirements are then (roughly) translated into story cards and the story cards are reviewed by the team and the customer.

With that background, I say that the story cards take a relatively minor role in driving day-to-day development. At the start of any iteration, the story cards are used to spin out tasks. Some of the tasks are features (the process should convert incoming data with a value of 'x' to the value of 'y'), or they could be technical (setup the demo server). Then, the team estimates complexity for the individual tasks. During an iteration, we look at the task cards -- not the story cards.

On a day-to-day basis, we tend to use Fitnesse to provide direction for the unit tests that need to be written. Our goal when looking at a new feature is to have a pair sit down and sketch out a Fitnesse test. Once that has been done, we'll sit down with the customer and make sure that the behavior outlined in the Fitnesse is what they expect. Then, we right the fixture code to clear all of the Method Not Found exceptions that the Fitnesse test initially causes. At this point we have a nice, red, failing test for a feature.

After getting the large test in place (and failing), we start looking at where the system needs to be extended, perhaps do a little whiteboarding, and start writing unit tests. The failing Fitnesse test helps keep us on target. Quite often, one of the developers in the pair will have to say, "now, what Fit test are we trying to make pass?" Just like with unit testing, we sometimes find other behaviors that need to be specified. Usually one half of the pair will pull off and capture enough information on a task card so that we don't forget it.

The shortcomings of Fitnesse have been well articulated (here and here and here). I'll say that the one I find to be most frustrating is lack of refactoring support. When I change the wording in my tests, I have to go change method names. But, since our projects are relatively small (1 - 2 months), we don't end up with so many Fitnesse tests that this is a large problem.

Because we use the Fitnesse tests to drive discussions with our customers, nobody has ever come back and said, "well, the tests that you've got in place are great, but the system isn't really doing what I want." While looking at Fitnesse, the customer does not forget what they wanted, and they often remember things they forgot to ask for initially. The story cards are not useless, they just don't get used much once the team gets going.

All in all, I'd say that we hit a pretty good flow of writing Fit tests, having conversations, writing unit tests, and making everything green. It's certainly possible that on a longer-term project with more features, we would find ourselves frustrated by the tools that we currently find to be productive.

Using Groovy to grep XML

2007-08-13T23:50:00.000-07:00

After attending some compelling presentations by Scott Davis at No Fluff Just Stuff, I have been playing with Groovy here and there when I've gotten the chance. At work, we've been working with a some software that's currently producing a pretty massive log file. We tried using Chainsaw to slice and dice it, but it wasn't giving us the functionality that we wanted. So, this was a perfect time to play with some Groovy.

Our input looks something like this:

<root>
<entry level="ERROR">
<message>
An error has occurred while parsing column FOO with value of BAR 23 in row 234
</message>
</entry>
<entry level="ERROR">
<message>
An error has occurred while parsing column FOO with value of BAR 52 in row 234
</message>
</entry>
<entry level="ERROR">
<message>
An error has occurred while parsing column FOO with value of FOOBAR 34 in row 234
</message>
</entry>
<entry level="ERROR">
<message>
An error has occurred while parsing column FOO with value of FOO52 in row 234
</message>
</entry>
</root>

Of course, the file is too massive to read through. For this particular error, we were interested in the unique values of FOO that we weren't handling. Here is the groovy to pop open the XML file and find the unique values

def findUniqueEntries(String inputPath, String search, String extract) { def uniqueMatches = new HashMap() //Input all of the XML def root = new XmlParser().parse(new File(inputPath)) //All the child nodes of the root node will be elements for (entry in root.children()) { //Assumes each has exactly one child text = entry.message[0].text() //Do a substring search first if (text.contains(search)) { //Strip out the failing value with a Regular Expression def matcher = text =~ extract uniqueValue = matcher[0][1] //For values we've seen before, increment the count if (uniqueMatches[uniqueValue] != null) { uniqueMatches[uniqueValue] += 1 } //For a new value, initialize the count else { uniqueMatches[uniqueValue] = 1 } } } //Print the values along with their occurance count for (match in uniqueMatches) { println match } //Print the number of unique matches, and the number of total matches. def uniqueMatchCount = uniqueMatches.size() def totalMatchCount = uniqueMatches.values().sum() println ('\nFound ' + uniqueMatchCount + ' unique matches in ' + totalMatchCount + ' total matches.\n') }

There are a couple of interesting things that made this really fun code to write:

1 - Navigating XML with Groovy is easy, and the syntax reads quite well. The code communicates the structure of the XML document as well as could be expected, I think.

2 - Groovy makes it really easy to work with Regular Expressions. No more pattern compiling.

3. The Groovy sum() extension means that we don't need to track the total number of matches, nor do we need to iterate through the HashMap at the end.

All in all, I'm enjoying playing with Groovy at the moment. I've found the barrier to entry to be pretty low. It will be interesting to see how we continue to use Groovy in the future.

Throw Away Code Must Be Thrown Away

2007-08-13T23:36:00.001-07:00

From time to time, it’s advantageous to take off my TDD hat a fling a small bit of code. I’ve found this is the quickest way to gain a bit of confidence in working with libraries that I haven’t touched before. This allows me to be sure that I know how to interface with the functionality that I need. After a quick proof-of-concept, I’ll know what parameters and classes are needed to get what I want.

My own personal problem with this has been developing the discipline to remove the code from the system once I’ve figured out what I’m after. Why do I think I need to discipline myself to do this? Simply put, my worst code is always the code that wasn’t written “test-first.” The spikes that I pull over into production code often cause problems when trying to get them under test coverage.

Conversely, I’ve found that following Test Driven Development yields code that is easier to test and frankly, better designed. TDD prevents a great deal of speculative development and over design. Therefore, it’s much better to step back from the initial spike and start over by writing tests.

I have found it much easier to prevent the spikes from getting attached to the project by putting them in a completely separate class. Name it “class ThrowAway” to help yourself remember.

Bottom line: Throw-away code must be thrown away.