In my previous post, I presented the new version of Windows Azure Toolkit for Social Games. It has simple games to demonstrate the use of Javascript, HTML 5 canvas, game moves processing, Azure worker roles and web roles. Let’s explore in this post the making of client game logic, in Javascript, using TDD and QUnit.
There are online tests at:
http://watgames4.cloudapp.net/Test
Let’s run the Tic Tac Toe Game Logic tests:
http://watgames4.cloudapp.net/Samples/ClientTest/TicTacToeGameTest
This page is using QUnit for client Javascript unit testing. I wrote about that library at:
The above page is testing the Tic Tac Toe logic. Remember, each game is implemented in parts, the logic is one of them:
The client code resides in TicTacToeGame.js inside the SocialGames.Web project. Their first lines:
TTTColor = { Empty: 0, Cross: 1, Circle: 2 };
function TicTacToeGame() {
this.board = [
[TTTColor.Empty, TTTColor.Empty, TTTColor.Empty],
[TTTColor.Empty, TTTColor.Empty, TTTColor.Empty],
[TTTColor.Empty, TTTColor.Empty, TTTColor.Empty]
];
}
TicTacToeGame.prototype.move = function (x, y, color) {
this.board[x][y] = color;
};
TicTacToeGame.prototype.isEmpty = function (x, y) {
return this.board[x][y] == TTTColor.Empty;
};
....
The client test page (TicTacToeGameTest.cshtml) was built at the same time, using a TDD (Test-Driven Development) approach. Look at first tests:
test("Create Empty Board", function () {
var game = new TicTacToeGame();
for (var x = 0; x < 3; x++)
for (var y = 0; y < 3; y++)
ok(game.isEmpty(x, y));
equal(game.isTie(), false);
equal(game.hasWinner(), false);
});
test("Valid Moves on Empty Board", function () {
var game = new TicTacToeGame();
for (var x = 0; x < 3; x++)
for (var y = 0; y < 3; y++) {
ok(game.isValid(x, y, TTTColor.Cross));
ok(game.isValid(x, y, TTTColor.Circle));
}
});
test("No Winner in Empty Board", function () {
var game = new TicTacToeGame();
equal(game.getWinner(), TTTColor.Empty);
});
test("Get Winner in First Row", function () {
var game = new TicTacToeGame();
game.move(0, 0, TTTColor.Cross);
game.move(1, 0, TTTColor.Cross);
game.move(2, 0, TTTColor.Cross);
equal(game.getWinner(), TTTColor.Cross);
equal(game.isTie(), false);
equal(game.hasWinner(), true);
});
The idea is to take baby steps, one test at a time, designing the game logic “API”, its expected behavior. In this way, you expend less time debugging in a dynamic language like Javascript, and you gain a test suite that can save your day in case of major refactoring. Look at the Four In A Row logic and client tests: you will find a similar approach.
Ok, not all can be easily tested, or build using TDD. Some of the game-agnostic services are using Ajax and Blob Storage, and to test them you must consider asynchronous Ajax calls. You can check:
http://watgames4.cloudapp.net/Test/ServerInterfaceTest
(You must be logged in using your Facebook or Windows Live ID, an example of use of Federated Security and Access Control Service (ACS))
This time, the system under test is the game-agnostic Server Interface:
There are some tricks in the test code (ServerInterfaceTest.cshmlt), an excerpt:
test("Call User/Verify", function () {
var success = function (result) { ok(true); start(); };
var error = ajaxGetError;
stop(10000);
expect(1);
si.sendAjaxGet(apiURL + "user/verify", success);
});
expect is a QUnit function that prepare the framework to receive 1 ok(true) sometime during the test run. That confirmation is included in callback function success that it will be called after the successful processing of the asynchronous call .sendAjaxGet. Async life is not easy ;-)
More code analysis is coming. And some adapt to use Node.js as game server.
Keep tuned!
Angel “Java” Lopez
