I've recently found cucumber to be a very nice BDD tool in web development. I'm curious, has anyone tried it in game development? Do you think it could work? I could imagine specifications like this:

Scenario: producing a unit
  Given I have built a barracks
    And I have enough money for a minigunner
  When I select the barracks
    And I click on the minigunner icon
    And I wait for a while
  Then I should see a minigunner within 10 meters of a barracks

A step definition could then look like this (if we were coding in Ruby with RSpec):

Then /I should see (.*) within (.*) of (.*)/ do |see_what_matcher, range, near_what_matcher|
  see_what = find_by_matcher(see_what_matcher)
  near_what = find_by_matcher(near_what_matcher)
  see_what.should be_within(range).of(near_what)
end

Similarly in an FPS:

Scenario: inflicting splash damage
  Given there is an opponent 5 meters north of me
    And I aim north of me
    And I hold a rocket launcher
  When I aim at the ground 4 meters ahead of me
    And I fire
    And I wait for a moment
  Then an opponent has not been hit directly by a rocket
    But an opponent has taken damage from a rocket

Some challenges I could think of: - Handling the passage of time without overspecifying ("wait for a while" instead of "wait for 15 seconds") might be tricky. - Talking about multiple objects of the same type. - I imagine some gameplay mechanics will be difficult to specify. Depends on the game, though. Still, the idea seems cool, but would it be worth the effort?

it seems like if you weren't careful, you could end up in quite a a href="">pickle...

Are you developing an online service that will provide constant feedback during development?

If no, then this type of agile iteration will come far from reaching the goals.

xDD methods require quick and constant feedback and evolve during development. This means that you need to have your target demographic using your service constantly, as well as having proxies aggregate feedback provided by them. This feedback should be made available daily and instantly acted upon.

If you are not working on service/on-line application, but plan to release at fixed deadlines (once per week, twice per week) then xDD approaches will fall short of expectations since you are very likely to side track into features, without actually having useful goals to pursue.

Agile methods trade planning for feedback. For longer release cycles (more than one week), Scrum is more suitable. For anything above a month, or anything that you will not be able to maintain once released, classic planning + dedicated test groups still wins out.

For projects with short lifecycle and without long-term strategy, xDD is overkill. Project will not live long enough to warrant being maintained, but will still absorb the double initial cost.

I agree that most agile methods as used in web development don't translate well to game development, but don't some game developers still use xDD (to some degree) as a coding method? The usual benefits, such as testable (=decoupled) API designs, YAGNI-avoidance, automated regression tests etc. should still apply, shouldn't they?

Cucumber simply looks like a rather clean and inspiring language to write integration tests in, though of course you could do the same things in a standard programming language.

Quote:Original post by 255
The usual benefits, such as testable (=decoupled) API designs, YAGNI-avoidance, automated regression tests etc. should still apply, shouldn't they?

Those are different from xDD.

Quote:Cucumber simply looks like a rather clean and inspiring language to write integration tests in, though of course you could do the same things in a standard programming language.

Unless you have constant feedback from users - who will tell you which tests to write?

With xDD there is usually next to no large scale documentation. So while each feature will be implemented perfectly, it will not converge towards the goal but devolve into featurities.

You can only write detailed tests if you have very specific requirements in mind, not only the what, but also how. With xDD, what is missing is why, which is provided by testing feedback.

If you had constant feedback "ninjas, and pirates, and guns and yellow button and click and ..." you'd prioritize those with regard to how well they fit into the long-term goals and how viable are they, and implement the top daily requests, test feedback or current changes. Without users, you'll end up implementing whatever you feel like that very moment, which ends up as a solution looking for a problem.

Which means if you want to finish some long-term goals on your own, you need specify them in adequate detail up front, so you don't drift away.

This is the reason why xDD works so well in business, where there are no longer term requirements, no long term strategy, but whatever customer wants or feels like, they get the same day.

xDD means write complete test first, and let tests guide the result.

Sorry, it seems we're talking about different things. The reason might be my liberal use of the word BDD/xDD. I'll try to clarify.

By bringing up cucumber I didn't mean to suggest adopting an agile BDD process. I just saw it as an elegant integration testing DSL that could potentially work nicely in a game project.

I suppose we don't even have to assume a test-first development style to ask the question I wanted to ask: is cucumber a good way of writing automated integration tests for games? I only assume (perhaps incorrectly) that some game developers actually write automated integration tests, either before the code or after.

Quote:Original post by Antheus

Quote:Original post by 255
The usual benefits, such as testable (=decoupled) API designs, YAGNI-avoidance, automated regression tests etc. should still apply, shouldn't they?

Those are different from xDD.

Those being what? What do you call the thing that leads to those desireable things but isn't xDD? That is probably all that I'm after.



You seem to be arguing against trying to copy an agile BDD process from web development as-is, but I don't think I've suggested anything like that. Still, for the sake of argument..

Quote:Original post by Antheus
Unless you have constant feedback from users - who will tell you which tests to write?

Whoever tells me what to implement next. Whoever does the planning and prioritizing. Does it need to be an end-user? Are you arguing against test-first coding in general or some specific process model involving it?