As a player, I want to easily start the game so that I can begin playing immediately.

[suchja]

Notes

• According to Jan we should focus on using the keyboard and avoid using the mouse when possible (talked to him today ;). - keep non-functional requirements NFR-1 - Ease of use in mind!
• Proposal is to rely on the arrow keys to start the game. That way the Snake gets a direction when it starts.
• Project structure and class design needs to consider NFR-3 - Extensibility (UI) as well as NFR-4 - Modular Design

Open Issues

• The Snake has at least one tail element, when it is initially placed on the screen. What happens when the user tries to start the game into the direction of the tail? Should the game immediately end?
  • Probably we should avoid ending the game within the first second. So discussing with user we agreed that it should be okay to start the Snake even in the direction of its tail. Assuming the tail is only one item at start.

Acceptance criteria

• [x] Snake starts moving into the direction of the first pressed arrow key
• [x] it is not possible to end the game with the first movement
• [x] Snake continuously moves into the direction initially chosen by user
• [x] Snake will reappear "on the other side" when hits the end of game board
• [x] Hint shown at the start of the game (see #5 ) should disappear

[suchja]

Adding this to milestone 0.1 as it relates to the core game.

[suchja]

ChangeLog: Moved #5 from here into a separate user story as it seems to me that it all together gets to large for one user story.

[suchja]

ChangeLog: Added acceptance criteria for letting snake "cross" the game board and added that the hint how to start the game should disappear.

[suchja]

Testing

This morning I made up my mind about TDD (see here. So now it is time to try TDD "the right way").

That means I try to use the following list of tests to guide the development.

List of Tests for this behavior

• [x] Pressing any other key (except arrow) does nothing to the snake or the game
• [x] Pressing any arrow key should move the snake's head into the according direction with its next move
• [x] Snake (head and body) move one tile every 250 ms
• [x] Snake head appears on the contrary side of the game board, if it leaves the game board on side
• [x] Snake body follows head with regards to leaving game board

ChangeLog

• Combined the 2 tests regarding arrow key into one based on this discussion.

Open Issues / Tasks

Based on the wonderful book Test Driven Development by example (written by Kent Beck), I'll also track todos and open issues as they arise in order to keep moving forward and not get distracted.

• Snake::executeMove moves body independently of head. Probably this will get us in some trouble.
• is it a problem that the Game::isStarted signal is emitted before Snake::setMoveDirection is executed?
• Do I need to test that the Game starts in NoMove "state"? If yes, how do I test that?
• According to MVVM it might be better to place the Timer inside the GameViewModel instead of the MainWindow. Check whether there is a possibility to do this while keeping up a good testability.
• QSignalSpy has some wired behavior. While I can use QSignalSpy another_signal(&game_dependency, &Game::isStarted) on the Game class, only QSignalSpy is_started_signal(&sut, SIGNAL(gameStarted())); works for the GameViewModel. No idea why that is.
• GameViewModel might require a signal userMessageUpdated. This would improve single responsibility and maybe allow separate interfaces for View (one MainWindow is using and one GameBoardView is using).

[suchja]

Starting with test Pressing any other key (except arrow) does nothing to the snake or the game

• Interface: Adding GameViewModel::processKeyboardAction(int key_code) : bool
  • This will be called by MainWindow and follows the EventFilter mechanism
  • returns True when key_code was handled
  • returns False when key_code was not handled and needs to be passed along for further processing
• Implementation: I guess the most part was already defined within the interface. So I should think about how to better separate design decisions for interface and implementation

Then I do have some logic here that I'll not test. Not sure how to integrate things like that into TDD. Anyhow, the MainWindow will get an EventFilter, which calls the newly implemented method in GameViewModel.

[suchja]

Somehow I have difficulties with the next test Pressing any arrow key should set the moving direction of the snake accordingly. This is somehow difficult to test AND it seems to me that it already has some kind of implementation decision in it. It talks about a moving direction. Although the snake obviously moves into a certain direction on the game board, the term moving direction to implies a certain state of a Snake object.

Wouldn't it make more sense to say Pressing any arrow key should move the snake's head into the according direction with its next move? This brings us to the following questions:

• What does it mean that the snake is not moving (before an arrow key is pressed)?
  • Probably this only comes up, because I'm already thinking (again) about the implementation. I was considering any timer and when it is started and the like. So we ignore it for the time being.
• What happens to the body in the next move, when the snake's head moves into a "new" direction.
  • Although it is a valid point, it currently has no importance, because for this user story the snake does not change its direction! It simply starts of in one direction and keeps going into that direction!

So I would argue that the real test required here is Pressing any arrow key will move the snake towards the implied direction with its next move. This would give me the following direction:

• Interface:
  • Game::setMovingDirection(...)
  • Game::executeMove()
  • Game::getSnakePosition()
• Implementation:
  • Game will forward the calls towards Snake. Thus Snake needs to have a similar interface!
  • globals.h will provide the Definition of enum class Direction. Thus Snake does not depend on Game and in the next step GameViewModel can use the Direction from there as well.
  • GameViewModel needs to call the new interface of Game.
• Tests:
  • I started with tests on Game as this seems to me as the core class
  • I skipped separate tests for Snake. Those would add (currently) no benefit.
  • GameViewModel should have similar tests. Even if they are (partially?) duplicate with those in Game. As the snakecore library should be independently useable, it should be okay to have test on both?
  • Additionally the GameViewModel needs to make the transition from the Key to the Direction. This should be tested as well!?!
  • With the tests for the GameViewModel it became also apparent that the Snake was missing movement of its body.

[suchja]

So next stop is:

Snake (head and body) move one tile every 250 ms

• Interface
  • Is already defined via GameViewModel::executeMove. Although I'm not sure whether I really like this way (should a timer be part of snakecore lib or maybe at least of the view model itself?), I'll stay with it to move ahead with full speed.
  • Game::isStarted() - signal - While going through this I recognized that we need a trigger to start the game. So probably removing the initial test around this wasn't a good idea!
• Tests
  • Game needs a test that its signal isStarted is emitted once movement changes from NoMove to something else.
  • Do I need to test that the Game starts in NoMove "state"? If yes, how do I test that?
  • There seems to be no additional tests, because the stuff in MainWindow has no tests.
• Implementation
  • Decided to keep the timer in the MainWindow (for the moment) although it might be better placed in GameViewModel.

Retrospective:

• The wired behavior of QSingalSpy as well as the question where to place the timer confused me. There was no flow at all and I'm still pretty uncertain whether everything works as expected.
• I'm not totally clear what exactly the problem was with regards to TDD. Probably the change was too large. Although I'm not clear how I could have divided it.
• Adding the SnakeView and integrating it into GameBoardView was a large chunk. So I should really learn how to use TDD in this UI-centric classes or at least learn how to better make small steps.
• It was good to have the AwesomeQtSnake-Spike ready. The concept for drawing the SnakeView as a QGraphicsItem could be used from there.

[suchja]

Next step is:

Snake head appears on the contrary side of the game board, if it leaves the game board on one side

• Behavior
  • Head appears on the contrary side and
    • body advances one tile
  • Head move forward one step and
    • first element of body appears on the contrary side as well,
    • remaining body advances
• Tests
  • [x] All elements of the snake (head and all entries in its body) need to pass the following tests.
    • [x] Snake element appears on the left side (0, 10), if it moves one step to the right and was on the right border (19, 10) before. (20,10) is already off the board, if it is (0, 0, 20, 20).
    • [x] Snake element appears on the right side (19, 10), if it moves one step left and was on the left border (0, 10) before. Assuming board dimension of (0, 0, 20, 20).
    • [x] Snake element appears on the upper side (10, 0), if it moves one step down and was on the bottom border (10, 19) before. (10,20) is already off the board, if it is (0, 0, 20, 20).
    • [x] Snake element appears on the bottom side (10, 19), if it moves one step up and was on the upper border (10, 0) before. Assuming board dimension of (0, 0, 20, 20).
  • [ ] The previous tests need to be passed by positions on the ViewModel/View. Thus GameViewModel requires similar tests.
• Interface
  • Although from a functional point of view it is not required, the Snake requires a setToHeadPosition(QPoint new_position) for testing.
• Implementation
  • I guess the SetToHeadPosition should also take the current movement direction into account, but for the current test scenarios this is not required. Therefore I skip it so far.
  • Except changes to the Snake no other changes are required. This is because the GameViewModel as well as the GameBoardView simply follow the Model. This is now really nice!
• Retrospective
  • It was a good idea to write down the excepted behavior as well as concrete test cases. Here I feel the Double Checking as defined in TDD works pretty well. I imagined the board and made up the examples. Then I implemented the test and could use the positions. Finally I thought about how to change the code.
  • The initial tests missed an implementation error for the left and upper border. This was because I set the snake immediately to the border, but when it moves towards the border the limits used in the implementation applied earlier. Therefore the snake never reached the first row/column. This only became apparent once I saw it on the game board.
  • Adding the Snake::setToHeadPosition() already felt strange when I decided to do so. If I hadn't done that, the error could not have passed the tests.
  • Thus it might not be a good idea to add something to the interface only for the tests. Instead I could have come up with a slightly more complicated test (it now includes a for loop, which I usually see as a "test smell").
  • Additionally setting the snake to a new position with the "test only" method took quite some time.

[suchja]

Final step is to update the user message!

• Behavior
  • Game is started by pressing any arrow key and the initially displayed user message should disappear
• Tests
  • press arrow key down and verify that user message in status bar disappears
  • press any other key except arrow keys and verify that message stays in statusbar
• Interface
  • Generally speaking we have the GameViewModel::getCurrentUserMessage(), GameViewModel::processKeyboardAction as well as the GameViewModel::gameStarted signal. This allows to transport all required information.
  • To better stick to Single Responsibility a separate GameViewModel::userMessageUpdated() signal might be a good idea. However, as the required behavior can be realized without it, we add to the todo list, but ignore it for the moment.
• Implementation
  • GameViewModel as well as MainWindow both have a startGame slot. This can be used to transport and update the message accordingly.
• Retrospective
  • I was already on my way on adding a dedicated signal for userMessageUpdated. However, writing down parts of this comment here reminded me that it is not necessary (at the moment).
  • So this was a fast and secure change. Celebrate!!!

[suchja]

Copied open todos/issues from this comment to #9

As all acceptance criteria are met and todos are stored, this user story will be closed now.