The Importance of Stubs

Wow, I haven't posted in a while. I'm still crunching away at the game but a few things have popped up at home that have kept me from spending too much time. Leaky basements and a new puppies tend to do that I guess.

Nothing new to report with the game, still just hammering away at the game's user stories. I did switch over from Continuum to Cruisecontrol for my integrated environment. I've been trying out git-svn with some success and liking it for the most part.

So to make this post a bit more interesting I decided to rant about something that I've seen in a couple of teams I've worked with both as a developer and as a coach. The issue is that of having dependencies on other teams for artifacts that are critical to my team's product. This is especially problematic with larger organizations pushing for an "enterprise" solution - which typically translates into multiple development teams working separately for months trying to configure an off-the-shelf, over-priced product and then throwing everything together in an integration nightmare and regression testing for a period that might out last the actual development time.

Being responsible for a product that you don't fully control all the moving pieces can be frustrating and at times paralyzing. But I've found a solution that's produced some good results: create a stub of everything that you depend on but don't control.

For example, if your team is building a web client that consumes services for all of your back-end work, stub out each of the services that you rely on. Define an interface that your team and the team building the service can agree upon and build a basic implementation.

If you're relying on a web service that provides search capabilities, get the WSDL and generate a client and service. Put just enough implementation into the service to make it functional. Have it return one of ten result sets based on ten different query strings - something simple but functional as far as inputs and outputs.

Once you have the stub in place, you can write your automated UATs (User Automated Tests) around your application using the stub and ensure that your application is processing the results correctly. Once your UATs are in place and you have your continuous integration environment, you can swap in their actual services and just kick off the build to verify the integration. This should make it fairly painless!

Now obviously the interfaces can change as the project continues but just make sure that when the changes occur, all dependent teams get an updated version of the interface. Then it's as simple as regenerating the stub service and client code and making a few adjustments here or there. Then run the UATs again to ensure that you have integrated the changes correctly so that the behavior of your application is still what the user expects.

I'm convinced that this practice alone will save large development departments millions of dollars of teams wasting their time trying to throw everything together at the last minute. And it will probably save developers the stress of the integration nightmare.

End rant.

What to do when you don't know what to do

The last story that I was working on required me to do some animation in Java3D, which I didn't how to do. So, I did a little Spike to learn a bit more about what was involved with that, and I finally finished up the story. With this on my mind, I thought I would spend some time talking about Spikes.

I think Spikes are one of the most misused parts of Agile. The general understanding of a Spike is that it is a research story. If you have questions about how to do your User Story, you spend time researching or spiking the questions that you have. I've seen different teams handle Spikes in different ways. The worst I have witnessed are spike stories that drag on from iteration to iteration. After a time, when something is finally delivered, it's not in a state that is usable, but too much time has been spent on it, so it winds up being put into the code base with no tests, no pair programing, etc. The best use of a Spike is to only use it when you don't know enough to estimate the story, then you spike until you know just enough to do the story. Any code that you write to answer those questions are considered "spike code" and you throw it out.

One really good practice to get into to avoid spike abuse is to always have your Spikes be time-boxed. You set a limit on the amount of time you will spend researching. Once that limit has been reached, the team can then review whether or not they need more time or need to possibly take a different route. If you can't learn enough within a day or so, to estimate, you really should reevaluate if that technology is worth the time. If an off the shelf product takes a week's worth of time to "spike" so that you know how to use it, maybe a simpler approach that doesn't involve that product is the better approach.

I've worked with some people that use the term "Spike" to justify taking a long time to writing crumby code that is meant to be used as a prototype. Truth is, that when they finally get to the point that they can write that code, they know enough to estimate the actual story and then begin working on it. Time spent on a spike after you have answered your question is no longer time that should be spent on spiking, but time spent working on the story.

I've also heard the phrase "architectural spike," which boils down to taking entirely too much time to write up a document to give to the team (that they'll probably never read) describing the solution with many charts and diagrams. And to me, that just goes against the concept of letting your tests drive your code and letting the design emerge from your refactoring.

So to recap, spikes are suppose to be a time-boxed (maybe a day) research efforts that answer enough questions so that you can estimate a story. Anything else, should be your standard test driven development based on satisfying acceptance criteria on your user stories.

Alright, so I blew through the first two stores that I was attempting:

1. User opens the application and sees the game board. Game board is a chess board (8 x 8 - alternating black and white squares) background is a gray. Camera is looking at the center from above and toward one side.

2. The user has one piece (a blue ball) on the board that is located on one side of the board on one of the center squares.

And up until now there was really no design to it. I started coding a class that had the capability of drawing on the 3D canvas and just kept going. Neither of these stories contain any user interaction yet so I was having a hard time coming up with testable code.

I eventually saw that there was a bit of logic needed for creating the checkered game board. So I thought I'd extract out something that would need to know how to do that. So I started going into an MVP pattern. I wanted the view to get something that it could use to create the proper rows and columns with the right alternating colors without too much logic. It wound up looking like this:

public void constructGrid(GameGridData data) {
 for (int x = 0; x < data.getTileData().length; x++) {
  for (int z = 0; z < data.getTileData()[0].length; z++) {
   Tile tile = new Tile(data.getTileData()[x][z]);
   board.addChild(tile);
  }
 }
}

The Tile class was an abstraction I had done to encapsulate the creation of the geometry and details of creating the individual squares. The TileData is a bean that I had to construct to keep the back-end models from knowing anything about the Java3D APIs. The GameGridData has the algorithm needed to get all the positions and colors in the right data structure (the TileData bean) that the view needed. I have a feeling that GameGridData may morph into an abstract class where subclasses will be specific for Chess boards or terrain looking grids or vast spans of black space. Once that was all pulled apart, I was able to construct a Model that generated these TileData beans and a Presenter that could communicate between the two.

Now what I have is a bunch of smaller classes that don't contain "view code" all of which are very testable! So that's where the first real signs of a design started to form. I had a need to be able to test what I was doing and no real good way of isolating the code that needed testing. So by separating out what was just calls to the framework's API (or my abstractions around the framework) and the logic needed for the correct calls, I was able to write a few tests and get things a bit more agile.

The third story actually got me into some user interaction:

3. The user can select a square on the board and the ball will move to that square. Movement is shown and not just a sudden change in location.

Selecting an object in Java3D is a bit more complicated than in Swing. Picking an object is basically translating a point that your mouse picked on the screen to a ray or cone that extends from the point down into the canvas and then seeing what objects intersect with that ray or cone. So my abstractions around the actual tiles in the grid by my Tile class paid off when I found out that the API will return the Node or Shape3D object that was in the intersection path. So I was able to retrieve the same TileData bean that I used to create the selected Tile object and then notify the presenters that are listening to the view.

And this is what it wound up looking like:

final PickCanvas pickCanvas = new PickCanvas(canvas3D, board);
pickCanvas.setMode(PickInfo.PICK_GEOMETRY);
pickCanvas.setTolerance(4.0f);

canvas3D.addMouseListener(new MouseAdapter() {
 @Override
 public void mouseClicked(MouseEvent mouseEvent) {
  pickCanvas.setShapeLocation(mouseEvent);
  PickInfo pickClosest = pickCanvas.pickClosest();
  if (pickClosest != null) {
   Tile tile = (Tile) pickClosest.getNode();
   selectedTile = tile.getTileData();
   tileSelectedListeners.notifyListeners();
  }
 }
});

So then I needed a way to move the user's game piece once the position selection took place. I made some similar refactorings to the code that created the user's piece with a MVP pattern. And then I let the model from the game grid and the model from the user piece be able to communicate with each other. And then the piece model notified it's presenter which in turn told the view to move the piece to the correct location.

public UserPieceModel(final IGameGridModel gameGridModel) {
 gameGridModel.addPositionSelectedListener(new IListener() {
  public void fireEvent() {
   currentPosition = gameGridModel.getSelectedPosition();
   adjustCurrentPositionForHeight();
   modelListenerManager.notifyListeners();
  }
 });
}

So this story is just about wrapped up. I currently just have the user's piece suddenly jumping to the new location but the story has some more specific requirements: "Movement is shown and not just a sudden change in location" I made it that way intentionally because I know nothing of Java3D's animation APIs. So now I'm just doing a quick spike to determine how to do that and then I'll be able to finish this story up and move on to the next.

So overall I think things are progressing nicely. I wasn't liking where this was going at first with a whole bunch of un-testable UI code but now it seems like I've got the start of a design that allows me to test what I'm creating. And really that's the point of this blog. I called it Emergent Development because that's what good software development should be. You start going and you realize you need something so that you can make it more testable, more loosely coupled, more flexible and so you interject a pattern or two so you can test your stuff and just keep going. So your design comes from need not from a over thought-out UML diagram that was created long before any real code started. Design comes as you need it, no sooner.

Doing a GUI application using TDD

Testing user interfaces is always a pain point when doing TDD GUI apps. Web development has been able to get around this a bit with automated UAT testing using tools like Selenium or Watir. But with GUI apps, there's no really good, cheap (as in free) UAT tools (if anyone knows of one, please let me know!!!).

So when I create a GUI app I use a MVP pattern where the View is really, really thin because it's just impossible to right good tests around it. In the past with Swing and SWT/RCP application, I've been able to have the view be fairly simple with an exposed getter/setter-ish API on it so that the Presenter can be tested on how it manipulates the View and the Model can have it's own tests for the business rules and that leaves not a whole bunch to test in the View. You don't really need tests for the implementat of view.getUsername() when all it does is read the text from a text field.

Here's a sample login MVP of what I'm talking about...
(I didn't compile this so don't complain if it doesn't actually work)

public class Presenter {
    public MyPresenter(final IView view, final IModel model) {
        view.addLoginListener(new IListener() {
            public void fireEvent() {
                try {
                    model.authenticate(view.getUsername(), 
                        view.getPassword());
                } catch (AuthenticationException e) {
                    view.showErrorMessage(e.getMessage());
                }
            }
        });
    }
}

The API exposed on the view is real simple:

public interface IView {
  void addLoginListener(IListener listener);
  String getUsername();
  String getPassword();
  void showErrorMessage(String errorMessage);
}

And the API on the model is real simple too:

public interface IModel {
    String authenticate(String username, String password) 
        throws AuthenticationException;
}

So this example makes the presenter very testable. And it separates out the need to know how the stuff is displayed to the user verses and how the actual authentication needs to happen. And the model is is left with a single responsibility and a very simple API. So testing the model is now real easy also. And the view now has no complicated functionality.

Even if you wanted to have some fields in the view that enable or disable based on options that the user has selected in other parts of the view, you can create another MVP triad for that and you could have another interface for that the view implements that might have some methods that look like this...

    void enableSubmitButton();
    void disableSubmitButton();

So the View doesn't even know what the state of the submit button is. It just knows how to enable or disable the field. Again, all the logic can go off to a Model so that it is testable and the Presenter just acts as a mediator between the View and Model interfaces which keeps the Presenter really testable.

As a general rule of thumb, you write a test for anything that could possibly break. And at the point of where this view is at, what would you be testing? That Swing is working? You shouldn't be testing their code, just yours.

Now in my game, I'm using Java3D for my "View" so that's going to be a fairly complicated piece that needs to be split as thin as possible to provide testability. Because really that should be your goal: how can I make this code testable? If I abstract something out and hide it behind an interface and inject it in, I can test my classes better.

Setuping up the Project

Ok, so I have a rough idea for the end result of my game and I started to write up some user stories.


Main Concept:

This is a board game where two players have a set of "pieces" that they can move around the board and attack the other player's pieces. The moves will be turn based: each turn the player gets to move one piece and cause one piece to perform an action. Actions may attack the other teams pieces which will may result in the termination of the attacked piece.



Ok, I'm hoping that with a little modification the game platform can provide the functionality for both a chess game and a Final Fantasy Tactics (great game by Squaresoft fyi for those who haven't played) style game.

User Stories:

User opens the application and sees the game board. Game board is a chess board (8 x 8 - alternating black and white squares) background is a gray. Camera is looking at the center from above and toward one side.

The user has one piece (a blue ball) on the board that is located on one side of the board.

The user can select a square on the board and the ball will move to that square. Movement is shown and not just a sudden change in location.

All movements are logged.

User can have eight balls. To move one, the user must select the ball to move first, then select where to move the piece.

The opponent will have 8 pieces also but of a different color.

User cannot move onto a square that is already occupied.

After the user moves a piece, the opponent will move one of its pieces in a random direction (no piece can move off of the board).

Pieces can move up to three square away.

When a user selects a piece to be moved, the squares that are within range will change color to indicate the possible ending positions for that piece. Attempts to move to a square that is not showing the indication is ignored.

User can choose to attack a piece belonging to the opponent if that piece is within 2 squares from the user's piece. To attack, the user selects the piece that they wish to attack with, then select the opponent's piece that is the target. The attack is logged.

Attacks are logged to the same log that the movements were logged.

Some visual representation of an attack between two pieces is shown.

Pieces have a sense of "health". Each piece can take two attacks before it is destroyed. Destroyed pieces simply disappear from the board.

Add an indicator for the health of the piece.

The pieces can be of different types:
- large, can only move 1 spaces but takes 3 hits to destroy
- medium, can move 2 and takes 2 hits to destroy
- small, can move 3 and takes 1 hit to destroy

Balls bounce in place while they wait their move.

The smaller the ball, the faster it bounces.

The pieces can be loaded in from an external model(s) - maybe spaceships.

When the game starts, the user can choose to play the CPU or play another player.

Network enabled games.

The user's stats are kept from game to game: wins, losses.

When the user starts the game they are asked who they are (username) so as to keep building on their stats.

The user's pieces' stats are kept: number of opponent pieces destroyed

Piece rank based on number of opponent pieces destroyed.

Upgradeable pieces based on number of opponent pieces destroyed.



It's a small backlog and it'll grow. And the stories that are further out are a bit more vague, but they'll become more clear when they start coming to the front.



Starting Development

In the meantime, I decided to setup my continuous integration environment. I am developing this in Java (the graphics done in Java3D) using Maven for my build and Continuum for my continuous integration. Java was chosen because I know it the best and I'm a bit more familiar with Java3D than other 3D programming APIs. Maven was chosen for the use of it's dependency management. I've written a couple of standalone applications in the past and I've refactored out some useful tools dealing with things like error handling and whatnot. And with Maven, it's real easy to include the dependency in the pom and not have to worry about it.

So I got the project all setup with automated builds going and email notifications upon failure. I really think that this is crucial for any project starting up. Get your CI environment up and running. Now I don't have any other developers joining my project at the moment, but non-the-less, it is vital to make sure that whatever you have in your repository is stable (tests pass) at all times.

Interesting bit on the email notifications... GMail has been gracious enough to allow external smtp access to their servers. So it made setting up the mail notifications really simple.



And now I'm all ready to start tackling the first story...

Starting to blog...

So I've been told that blogs are good to get your ideas down and let others comment and possibly help you out occasionally. So here's my go at it. I'm a software engineer by trade and by hobby. I've been indoctrinated into the Agile software methodologies and I'm starting to put them into practice, not just at work where we're required to, but at home in my little side projects.

So I also have a hobby of videogaming and that tends to creep its way into my hobby of writing software. I've had grand schemes of writing the most amazing game that's interesting, replayable, exensible and just generally really fun. So I've had several failed attempts and I keep them all in my local SVN repo and occassionally dig them out and remember why I stopped that approach.

I think the reason why I fail most often in my attempts is that I try to do too much. In Agile terms, my stories are entirely too big. So I've decided that I need a backlog of stories that I can massage down to what would be doable and then focus on each one and get a sence of accomplishment and direction of where I'm going next. I've also decided to scale down the scope of my game. For the moment, it will involve moving pieces around a board and possibly taking your opponents pieces. Sounds very checkeredy but I figure that if I can start there, I can build uppon it. Maybe make it multiplayer, then make it networkable, then be able to load in different pieces, then make the board changeable. Then maybe I can pull out a framework that would allow me to create great extensible game that I know everyone will love and want to play! ... maybe...

Ok, first things first. Gotta get a backlog to work with. In order to do that, I need a good game concept. So that will be this weeks task. Some sort of game concept and the beginning of a backlog. And next week I'll plan on doing a release planning and start in on the fun.