BDD style tests for bidding

BDD stands for Behavior Driven Development, and it is one of those 2nd generation agile practices that I found difficult to buy into. BDD style tests follow the pattern: "given (some initial conditions), when (some action is taken), then (expect result)." This template seemed like such a no-brainer, that I could not see how it could warrant a separate name and whole movement formed around it. But then TDD itself (Test Driven Development) also is simple to define, and yet strict adherence to it forces revolutionary changes in a developer's mindset. Take a look at the following test written without BDD, which uses the latest evolution of bidding domain classes to demonstrate when to raise partner's major suit:

public void testRaisePartnersMajorDespiteStrongerMinor() {
  auction.bid(ONE_HEARTS);
  auction.bid(PASS);
  BiddingAgent ba = new BiddingAgent(auction, 
    new Hand("K,10,7,6","A,9,8,3", "A,8,6,4,2", ""));
  assertEquals(THREE_HEARTS, ba.getBid());
}

Now note how much easier it is to understand, when code follows the BDD template:

public void testRaisePartnersMajorDespiteStrongerMinor() {
  givenBidding(ONE_HEARTS, PASS);
  andPlayersCards("K,10,7,6", "A,9,8,3", "A,8,6,4,2", "");
  expectPlayerToBid(THREE_HEARTS);
}

The reason for this leap in expressiveness is that there's certain amount of useless ceremony around the domain objects, and that ceremony detracts from clarity of intent. By enforcing a strict BDD style on the tests, it's harder to be distracted by the ceremony. BDD puts focus on how the domain is modeled in human language, not in the code. The code model is decoupled from the spec by methods describing the context: givenBidding(), andPlayersCards(), and expectPlayerToBid(). One payoff of this approach is that hundreds of unit tests do not have to be modified when some aspects of the model are refactored. Another result is a set of test that can be shown to domain experts for verification. Both of these give boost to productivity.

Gnubridge vision statement - draft

Gnubridge has picked up a lot of momentum lately, and so I think it is time to define what it is and what it is going to be over the next few years. In many ways Gnubridge is still very immature, and so its version number is modestly kept below 1.0. This vision statement should help narrow down what it's going to take to make a 1.0 release, by giving the principles by which features should be prioritized or outright rejected. Please help shape this document by giving your input.

Gnubridge is a software program to play contract bridge. It aims to be a player's entry into the world of bridge software. This is accomplished through the following cardinal characteristics:

• Multiplatform deployment. By using Java and staying platform-agnostic, Gnubridge is available anywhere where Java runs.
• Gnubridge will be a strong opponent and a strong partner. What's under the hood is more important than the user interface, and enhancements in both bidding and deal playing will be given priority.
• Simplicity through ease of user experience. It should be ready to go out of the box: no configuration, no questions to answer for the users (like Gnuchess). New options and graphic interface features should be introduced with caution, with original behavior being the default on each upgrade. It is better to support fewer features than to confuse a mainstream user with obscure options and buttons. As a result, Gnubridge should not have many intimidating menus characteristic "rich" interface applications, and advanced options should be hidden far away from the user.
• Simplicity through deployment. Gnubridge should be distributed and run as a single file (unlike Gnuchess). The project will err on the side of including fewer features rather than making installation and management complicated. Also, no platform-specific installation packages will be supported at this point.
• Frequent, small, releases. If a piece of functionality provides value to players, it will make a separate release. One or more releases a month should be the norm.
• No bugs. Bugs will be fixed first. Automated tests will be written to expose bugs.

Gnubridge also has another community it serves - the developers. It should give developers a chance to demonstrate their skills, learn from each other, push the state of the art in game playing algorithms and apply agile development methodology on an open source project. Test driven development, collective code ownership, simplicity of design, and refactoring will be practiced on the project. Automated tools will provide additional feedback on the overall state of code. These will include continuous integration, static analysis, and test coverage.

Here is a brief sketch of what the future looks like.

Version 1.0

Target date: April 1, 2010.
Gameplay to implement most of American Standard convention, as covered in Pavlicek's Bridge basics. Support for doubles and redoubles. Duplicate bridge scoring.
User features: save and load a game. When restarting load a last unfinished game. Replay and rebid a game. Reset score. Force a computer to play before allotted time runs out.
Community: rss feed for Gnubridge updates.
Development: save junit results on CI server. Meet the target code coverage metrics.

Version 2.0

Target date: January 1, 2011.
Gameplay to implement American Standard and most other conventions with options. Bidding to include explanations. Double-dummy solver to include partition search. Double-dummy to include explanation of moves (for analysis mode).
User features: analysis mode allowing user to configure cards in a deal, force that certain cards are played, take back a move, and get computer recommendation.
Community: vote on features, easy feedback, easy debugging.
Development: static analysis tools, produce crap4j metrics, produce Emma plugin metrics, migrate to github, migrate CI to runcoderun.

Version 3.0

Target date: 2012
Network play: play with any number of partners against each other or computer.
Search algorithm no longer knows everyones cards.
Gnubridge enters a tournament against other computer programs.