Angel \”Java\” Lopez on Blog

December 19, 2011

Social Games Programming (Part 6) Testing Game and Service with TDD and QUnit

Filed under: .NET, Azure, Game Development, QUnit, Test-Driven Development — ajlopez @ 8:44 am

Previous Post
Next Post

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:

TDD with Javascript and QUnit

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

http://www.ajlopez.com

http://twitter.com/ajlopez

August 19, 2011

AjLisp in Javascript (Part 1) Atoms, Lists and TDD

Filed under: AjLisp, JavaScript, Lisp, QUnit, Test-Driven Development — ajlopez @ 10:59 am

Next Post

I’m rewriting my AjLisp interpreter using Javascript. I think that a Lisp interpreter is a good project to learn a language: simple, bounded but not trivial. I would never have begun this project without TDD (Test-Driven Development): Javascript is so dynamic and the tools I’m using (the browser, plain text editors) are so limited, that this project have been hard without the help of TDD. The practice of TDD gives me fun, doing baby steps and it helps me to explore good design.

The code (with parser, many primitive forms, some macro procession, work in progress) is at GitHub:

https://github.com/ajlopez/AjLispJs

The code is in one file: https://github.com/ajlopez/AjLispJs/blob/master/src/ajlisp.js

I’m using QUnit for tests:

The implementation uses the namespace pattern:

AjLisp = function() {
// ...
}();

The namespace is the result of evaluate a function. This function returns an object with the public members of the namespace:

return {
	// Classes
	List: List,
	Environment: Environment,
	Atom: Atom,
	Closure: Closure,
	Lexer: Lexer,
	TokenType: TokenType,
	Parser: Parser,
	
	// Functions
	makeList: makeList,
	isAtom: isAtom,
	isList: isList,
	isNil: isNil,
	asString: asString,
	evaluate: evaluate,
	
	// Top Environment
	environment: environment
}

As usual, a Lisp interpreter should support lists and atoms. Partial code:

function List(first, rest) {
	function getFirst() {
		return first;
	}
	
	function getRest() {
		return rest;
	}
	
	this.first = getFirst;
	this.rest = getRest;
}
List.prototype.isAtom = function() { return false; }
List.prototype.isList = function() { return true; }
List.prototype.evaluate = function(environment) 
{
	var form = this.first().evaluate(environment);		
	return form.apply(this, environment);
}	
// ...

Note that the first and rest part of a list are encapsulated in the constructor closure. They are inmutable, and can be accesed by functions aList.first(), aList.rest(). I should evaluate the impact of all those closure at list construction. But they are relative light.

Atom implementation is simple:

function Atom(name) {
	this.evaluate = function(environment) {
		return environment.getValue(name);
	};
	
	this.name = function() { return name; };
}
Atom.prototype.isAtom = function() { return true; }
Atom.prototype.isList = function() { return false; }
Atom.prototype.asString = function() { return this.name(); }
Atom.prototype.equals = function(atom)
{
	if (isNil(atom) || !isAtom(atom))
		return false;
		
	return this.name() == atom.name();
}

The atom evaluation is based in an enviroment (association of names to values) and the atom name. Numbers, strings are direct Javascript objects and they don't need to be implemented as atoms. In a “classical” Lisp implementation, all elements are SExpressions (symbolic expressions) capable of being evaluated. Now, I have AjLisp.evaluate that accepts any Javascript object and detect if it can be evaluated in an environment:

function evaluate(x, environment)
{
	if (x === null || x === undefined)
		return x;
		
	if (x.evaluate != undefined && typeof(x.evaluate) == "function")
		return x.evaluate(environment);
		
	return x;
}

Atom tests:

test("Atom", function() {
	var environment = new AjLisp.Environment();
	environment.setValue("one", 1);
	var one = new AjLisp.Atom("one");
	equal(one.evaluate(environment), 1);
	ok(one.isAtom());
	equal(one.isList(), false);
	ok(AjLisp.isAtom(one));
	equal(AjLisp.isList(one), false);
	equal(one.asString(), "one");
	equal(one.equals(one), true);
	var one2 = new AjLisp.Atom("one");
	equal(one.equals(one2), true);
});

Test exercising list behavior:

test("List", function() {
	var list = new AjLisp.List(1,2);
	equals(list.first(), 1);
	equals(list.rest(), 2);
	equal(list.isAtom(),false);
	equal(list.isList(),true);
	equal(AjLisp.isAtom(list), false);
	equal(AjLisp.isList(list), true);
	equal(list.asString(), "(1.2)");
	equal(list.equals(list), true);
	var list2 = new AjLisp.List(1,2);
	equal(list.equals(list2), true);
	equal(list2.equals(list), true);
	var list3 = AjLisp.makeList(1,2,3);
	equal(list.equals(list3), false);
	equal(list3.equals(list), false);
	list = AjLisp.makeList(null, null);
	ok(list.first() === null);
	ok(list.rest().first() === null);
});

Pending topics: environment implementation, list evaluation, forms and special forms, parser, lambda, mlambda, flambda. Lot of fun! ;-)

Keep tuned!

Angel “Java” Lopez

http://www.ajlopez.com

http://twitter.com/ajlopez

July 11, 2011

TDD with Javascript and QUnit

Filed under: JavaScript, QUnit, Test-Driven Development — ajlopez @ 9:49 am

This week end, I started to write a lisp interpreter using Javascript. The code is at

https://github.com/ajlopez/AjLispJs

But the key point: I’m using TDD (Test-Driven Development). I couldn’t start such project using traditional development: I’m still not proficient in Javascript. Using TDD is the way to start mastering Javascript idioms and patterns. Meanwhile, I’m writting a Javascript interpreter in C#, see:

https://github.com/ajlopez/AjScript

Last week, I stated to use QUnit TDD framework in a customer project. You can download it from:

https://github.com/jquery/qunit

After expanding the content (I downloaded the .zip file), you can launch the index.html file in the test directory. The result:

How to start a test? I copied qunit.js, qunit.css to a new directory, and I added a jquery source code file to it. Then, I created a new index.html with content:

<html>
<head>
<meta charset="UTF-8" />
<title>QUnit First Test</title><link rel="stylesheet" href="qunit.css" type="text/css" media="screen"><script type="text/javascript" src="jquery-1.6.2.min.js"></script>
<script type="text/javascript" src="qunit.js"></script>
</head>
<body>
<h1 id="qunit-header">QUnit First Test</h1>
<h2 id="qunit-banner"></h2>
<div id="qunit-testrunner-toolbar"></div><h2 id="qunit-userAgent"></h2>
<ol id="qunit-tests"></ol><div id="qunit-fixture">test markup</div></body>
</html>

The page reference JQuery and QUnit. The initial markup is important: QUnit will fill it with the test results. The result:

Before closing tag </body> I added an script fragment, with the initial tests (the simplest one

<script type="text/javascript">
	
    test("First Test", function() {
	same(3-1,2);
    });</script>

The test is green:

Note the use of $ JQuery function to register the code to execute AT THE END of the load of document.

You could add some test for a classic Calculator:

test("Calculator", function() {
    var calculator = new Calculator();
    equal(calculator.add(3,2), 5);});

Now, the second test is red:

I wrote the new calculator.js file, with the minimal code to pass the test:

function Calculator() {
	this.add = function(x, y) { return x+y; }
}

I added the reference in index.html:

	<script type="text/javascript" src="calculator.js"></script>

and re-load the page:

All is Ok! You can use your preferred editor. No IDE is needed. 

And you can learn Javascript (classes, prototypes, namespaces, scopes, closures) writing code using TDD.

Links:

Script Junkie | jQuery Test-Driven Development http://msdn.microsoft.com/en-us/scriptjunkie/ff452703.aspx

QUnit – jQuery JavaScript Library

http://docs.jquery.com/QUnit

My links

http://delicious.com/ajlopez/javascript+tdd

You can download this simple example from my Skydrive: QUnit01.zip. Next steps: write about AjLispJs, the Lisp interpreter I’m writing using TDD.

Keep tuned!

Angel “Java” Lopez

http://www.ajlopez.com

http://twitter.com/ajlopez

The Shocking Blue Green Theme. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

Join 66 other followers