Code Rally: a head to head competition of two or more programmers.

The Concept: each coder is given a problem to solve. The winner is simply the best time. However, modifications are made to time based on performance and penalties.

The Arena: two systems with a divider between them so they can’t cheat. Each station has a projector that displays on the wall behind the coder. This way an audience can view the competition.

The Racers: any set of coders or events could be used, singles, pairs, teams, relays, etc.

Think of the waterfall model as a set of stairs. Each step is a smooth surface that when you reach the end drops off to the next step. The software, service, application, etc. that the company is trying to produce is like a bicycle. The company wants to ride this bicycle from the top, the concept, to the bottom, the market. The result is a bumpy ride. The bicycle makes it to the bottom, sometimes, but sometimes the wheels fall off, or the whole bicycle just falls apart.

Think of the Agile process as a smooth ramp from the top to the bottom, similar to the appearance of a burn down chart. Riding the bicycle down the ramp is not only smooth but quick. Once the bicycle reaches the bottom it is in pristine condition.

So, how do you change a stair case into a ramp? The answer: start shaving down the stairs to smooth out the transitions. We try to do this by introducing Agile methodologies here and there in the process. Typically, this process starts near the top of the staircase, development.

Part of the problem with this approach is that by only targeting development the entire software delivery process is not addressed. If groups like QA or systems support are left out of the Agile process, then the top of the stair case may be smooth but the steps at the bottom of the staircase still result in a bumpy ride.

Picture this process: development completes its final iteration and produces a release candidate. Then QA tests it and finds some show stopping bugs. First, this means that we as a team failed to fail early. Second, we are still completing all the code then throwing it over the wall to QA. (Sounds like a waterfall, to me.)

And what if we fail to integrate systems support early into the process? If the application the team just wrote needs 6 new servers in order to run in a production environment and we’ve waited until QA has finished, we could be set back several weeks while we wait for the systems to be ordered, delivered, and setup. Again, if the systems people were involved early in the process, these lead time items could have been ready and waiting.

In order to smooth out these stairs at the bottom we need to include these groups early into the process. Pair a QA person with a developer at the beginning of a new feature. This gives QA an early glimpse at the features that the will need to test. They can then provide testing at verification that would allow QA to verify each feature as a stakeholder.

Also, assign stories that pair team members with members of systems support to set up dev, qa, and production environments. That way if any hardware, rack space, networking, etc. needs to be allocated the systems people can get those early in the process.

By including QA and Systems administration into the Agile team space the staircase that represents waterfall methodologies can be smoothed into a graceful Agile ramp.

I suggest that TDD should start at the story level. Story level tests run as if they were run against the software in a production environment. Testing at this level is also called black box, system, or end to end testing.

Consider the following system. A web service that is deployed on an application server that retrieves information from a database. The frameworks, languages, and application names are irrelevant for the example as these are black box tests. We need not be concerned about the inner works. In addition there is a requirement or story that reads like this:

As an end user I want a web service that will give me the total count of books in the library so that I can quickly provide usage numbers to management.

Q: What do we need to show to the product owner to prove that this story has been completed?

A: A working web service that retrieves the number of books in the library.

So let’s do this with a test that can be automated and become part of the regression test suite. This will ensure we don’t break this feature in the future.

The Maven2 build approach to integration tests has some issues:

• No convention for separate source directory for IT tests.
• No default test runner for the integration-test phase.

Three solutions presented themselves for handling the IT (integration) tests.

1. Use the failsafe plugin. (http://mojo.codehaus.org/failsafe-maven-plugin/) This uses naming conventions to build up a test suite. However, this approach can be broken since JUnit 4 allows test classes to use any name, thus providing unit tests and integration tests to get confused.
2. Hack the maven script to force the test compilation and test running of a separate integration test source directory. This approach could take a long time to develop correctly, however, it’s a pay once and reuse type of solution. Could also be difficult to maintain unless you’re a Maven2 guru. (Ha, that rhymes)
3. Separate the integration tests into a different project. This allows all the integration tests to be centrally located and run using the Maven conventional src/test/java directory. Tests can easy to copied over into a basic archetype with their own dependencies. Also this project can be independently executed on the CI. Should be simple to setup and follows the SRP. (Single Responsibility Principle)

The third option was the selected solution. If anyone else has faced this issue and has a different/better solution, please comment.

Here’s my definitions currently (They may change if I hear a good arguement)

End-to-end: Any test that is running with all servers, data sources, scripts, etc. and closely resembles production environment execution.

Story Test: An End-to-end test or tests that prove a story has been completed. These should be used in business verification.

Integration Test: A test that runs from an entry point to a system and tests a path through the system. Typically with external systems mocked out. These tests are useful for verifying framework configurations and inter-class communications.

Unit Test: These test should be small fast an isolated tests that fully test the business logic of the smallest entity. Isolation means that all external dependencies to the unit have been mocked.