One thing that's been on our mind for a while is how to do test first with Jemini. I want to stay away from terms like BDD, TDD, and integration testing because a game/simulator is a totally different realm than a sequential webapp or GUI app, and we shouldn't limit our thinking about how we approach things.

It's highly recommended that any complex game logic be moved out to a behavior. That behavior is an API that your game designer (even if that's you) will consume. That behavior should be tested with your favorite unit testing framework (like RSpec). Have have lots of examples for various behaviors in the Jemini code itself if you need an example.

So how do we do our high level integration tests? This is what I came up with using Cucumber, my integration testing tool of choice, on the Life Tank. LifeTank is our most polished game at time of writing.

Feature:
  As a player
  I should be able to control a tank

  Scenario: Moving
    Given there is a test level
    And   the level uses physics
    And   there is ground
    And   gravity is set to 5.0
    And   there is a tank tied to player 1
    And   player 1's tank is positioned just above the ground in the center of the level
    When  player 1 holds the "a" key for 5 seconds
    Then  the tank is on the left side

  Scenario: Shooting Shells
    Given there is a test level
    And   the level uses physics
    And   there is ground
    And   gravity is set to 5.0
    And   there is a tank tied to player 1
    And   there is a tank tied to player 2
    And   player 1's tank is positioned just above the ground in the center of the level
    And   player 1's tank tank's angle is at 180 degrees

    When  the game runs for 5 seconds
    And   player 1 presses the "space" key
    Then  there should be a shell game object
    When  the game runs for 2 seconds
    Then  player two is not at full health
    Then  the shell is gone

I could refactor a few of these, but it's mostly going to be custom stuff. A lot of physics gets used in LifeTank, but it's hard or not useful to pull those out into steps. Another facet is that LifeTank has randomly generated terrain. Some slopes in the terrain are deliberately too steep to climb. This makes it hard to test moving without using some completely different configuration - at which point we aren't doing an integration test.

I think the best way to tackle this is view the game as a system or a simulation. We want to see a lot of objects interacting with each other in similar ways, and more importantly we want to the game to be testable in a way that allows us to define what's fun. Fun means the tank shells go up and come down just right. It means that the shells can only be fired so far, etc. It's hard to get a machine to do this in precise, numerical terms.

I'd like to see an app that allows us to run a mocked version of our game in an automated fashion, but still allow us to verify that things worked well. This can be used in a test-first manner that allows us to tweak code and values until we get things right where we ant them.

These are my stories I've written up for this app:

• As a designer I should be able to create a new test.
• As a designer I should be able to see a list of Jemini core game objects
• As a designer I should be able to see a list of game objects for my project
• As a designer I should be able to add game objects to the test
• As a designer I should be able to select which managers I want my test to use
• As a designer I should be able to specify code to be evaled in order to create each game object for the objects ctor
• (*) As a designer I should be able to specify fields to adjust on any game object
• As a designer I should be able to see a list of game objects I've added to the test
• As a designer I should be able to record a test
• As a designer I should be able to play a test
• As a designer I should be able to loop a test
• (*)As a designer I should be able to adjust fields while the test is playing/looping so I can see changes in realtime
• (*)As a designer I should be able to save the field changes to the game object
• As a designer I should be able to see the test run like it were a game

* is some nice features that won't get done on version 1

Let me know what you think. I think this could be a really helpful tool for us going forward!

Jay, My main concern with Cucumber tests is that Cucumber seems to be really good for integration testing, but what you're seeing there is something along the lines of RSpec testing - instead of starting the game and playing it, we're now just seeing how a few particular things operate in highly controlled environments. This is not a bad thing, but I don't think we can truly achieve integration testing.

That said, your steps are much better than mine. I'm open to us going both directions at the same time, but I'd like your help with the Cucumber steps (and what level of steps we're going to define for all of our behaviors).

Just at a gut I think simulation tests vs cucumber is going to take a relatively equal amount of work. Which is more useful to us now and going forward?

Remember that Jemini stole Rails' inflector. You can camelize.constantize on the string you get back. You aren't actually using the $n vars are you? (:

Just make the method global (on Object). I have some tests for a project that do the same thing. You're pretty much making it global anyways by including it in the world. Our behavior system should prevent collisions with object_for if someone gets clever and tries to use that for a production behavior d:

No, you can still use instance variables. I took your existing object_for code and modified it. If you make a file and drop this in the support dir (env gets generated typically, so leave it alone), you'll get the desired effect without feeling like a giant kludge:

def object_for(name)
  case name

  when /the tank/
    @tank

  # Add more mappings here.

  else
    raise "Can't find mapping from \"#{name}\" to an object.\n" +
      "Now, go and add a mapping in #{__FILE__}"
  end
end

Note the lack of module and World call. This puts a method on Object since the context of execution is on Object.

Granted, everything gets object_for. However, it's contextual with use of instance vars. Since it's on object, it's also the first thing to be overridden if someone decides to get cute.

You can rapidly apply deltas to the app's update method to simulate the passage of time. I recommend this is the only way that time elapses in line-based tests, because you don't want assertions on a different thread elapsing time, or allowing an update to go by between assertions.