CODEWITHSUNDEEP
tddbdd
Yuriy Votintsev
Yuriy Votintsev

Reputation: 15

What minimal first test I should write to start in BDD?

I am learning BDD and trying to make very simple game. Player see some polygon shape and need to guess it's area by expanding circle spot. To guess player need to hold finger on screen (mobile game) for some time to expand circle to desired size. If circle's area is near shape area, thep player wins.

Now i want to create first minimal test to start developing, but I can't figure out this test. This is the most simple test that I write (in bdd style):

public partial class GuessShapeSize_Feature
    {
        [Test]
        public void RightGuess_Scenario()
        {
            Given_expanding_spot_expand_speed_is (5.0f);
            Given_shape_has_area_of (15.0f);
            When_player_holds_finger_for_seconds (3.0f);
            Then_player_guess_result_is (GuessResult.Success);
        }
    }

The problem here is that it is complex test that required around 5 classes: Level (container for everything happens here and checks for result), Shape (to guess), PlayerInput (hold and release finger), CircleSpot (that expands over time), TimeManager (i need to fake 3 seconds elapsed).

I can't name this test really simple for the first test. But I can't imagine any simpler test. What should i do in this situtation?

Upvotes: 1

Views: 146

Answers (2)

Lunivore
Lunivore

Reputation: 17612

You don't really need 5 classses for that first answer. All you need is an empty API or UI, and something which always returns GuessResult.Success.

The time manager will only be used from within the scenario (and is always set to 3 seconds for now).

If that behaviour isn't rich enough (well, of course it isn't!) then what scenario comes next? Can you think of an example where your game should return something other than GameResult.Success?

Start by making one scenario at a time pass in the simplest possible way. When it isn't enough, change it.

It's absolutely fine to have the classes of your design in mind, but make it simple, and refactor as you go to meet that design.

As you break out other classes, you'll be delegating parts of the system behaviour to those classes. Some things will be better expressed as behaviour of classes than full system stuff (probably the rules around area calculation, for example) so write an example of how the class behaves from the API / UI's point of view (TDD). This is the "outside-in" of BDD.

This will help you to keep a good Test Pyramid (lots of unit tests, few scenarios).

Don't forget to talk to someone about what it is you're doing, even if it's a rubber duck.

Upvotes: 2

GhostCat
GhostCat

Reputation: 140457

Think smaller, meaning: look at the "building blocks" that your overall experience requires:

  • You need an expanding spot. What about a test that simply tests that you have such an expanding thing?
  • Then: that expanding spot will at some point hit a hard limit. So, write a test to ensure the spot grows to that limit, but not beyond.
  • Next thing: user input. Write a test showing the growing shape and test the required user interactions (without deciding about winning or loosing)
  • And then when all these things work, then you can come back to the test you already have: the full user experience, maybe in different flavors to represent the winning and losing case.

Upvotes: 1

Related Questions