Unit test for as3 project

[Moshe Shein]

I have a general question: What is the best way to do unit tests in / on an AS3 project?

[creatify]

This all depends on how the application is developed. If your app is set up with some type of MVC system — you should be able to create a test class with a timer that fires random events and logs the data to simulate a random user input — that way you can just let it run and check the logs frequently to determine the stability.

[TheCanadian]

This all depends on how the application is developed. If your app is set up with some type of MVC system — you should be able to create a test class with a timer that fires random events and logs the data to simulate a random user input — that way you can just let it run and check the logs frequently to determine the stability.

I don't know if that's unit testing so much as it is just testing. Unit testing ensures individual modules (classes, methods, etc) function correctly on their own, given the correct test data, and are able to handle incorrect data. I usually do unit testing in a separate file. Usually I just open a new .fla, paste in the code I want to unit test and then input every possible combination of types of data that could conceivably be encountered. For instance, a possible unit test for the signum function would be:

trace(sgn(2)) //do positive numbers work?
trace(sgn(0)) //does zero work?
trace(sgn(-2)) //do negative numbers work?
trace(sgn(NaN)) //what happens when NaN is encountered?
function sgn(x:Number):int {
	return x > 0 ? 1 : x < 0 ? -1 : 0
}

And that unit test actually revealed that sgn(NaN) returns 0, which doesn't make any sense. So I might rewrite the function to this:

function sgn(x:Number):Number {
	if(isNaN(x)) return NaN
	return x > 0 ? 1 : x < 0 ? -1 : 0
}

or this:

function sgn(x:Number):int {
	if(isNaN(x)) return int.MAX_VALUE
	return x > 0 ? 1 : x < 0 ? -1 : 0
}

And then unit test again! Since NaN is not included in int and I'd like to keep the return of sgn as int and I don't like using some arbitrary number, I might even require that the NaN check be done by the caller of sgn, so I'd need to unit test that part next.

[Krilnon]

If you're interested in doing unit tests on a project that has a GUI, an alternative to dispatching fake user input events is to write your GUI unit tests as Sikuli scripts. They're scripts that run on the pixels displayed by your application, rather than scripts that need to know something about its internal state. In the case of GUIs, the type of module that you end up testing is usually something like a "component"... like a scrollbar or list view or whatever.

[theCodeBot]

If you're interested in doing unit tests on a project that has a GUI, an alternative to dispatching fake user input events is to write your GUI unit tests as Sikuli scripts. They're scripts that run on the pixels displayed by your application, rather than scripts that need to know something about its internal state. In the case of GUIs, the type of module that you end up testing is usually something like a "component"... like a scrollbar or list view or whatever.

Okay, that Sikuli stuff is pretty awesome looking. Considering that it's Jython based, I'm curious if they plan on porting it to Windows, and/or (wishful thinking) some of the more popular X window managers?

Regarding the original question, you're basically stuck writing your own code to test non-visual stuff - I do not know of anything like JUnit for Actionscript, though I invite someone to prove me wrong. Testing visual stuff is definitely tougher, and you WOULD need something such as Sikuli as Krilnon pointed out. Though, since you have access to the application code, you could probably write some custom script to fire MouseEvents and KeyboardEvents at the stage, and accomplish much of the same.

[wvxvw]

If you were wondering more about methodology, rather then particular tools, then I've discovered that the biggest problem is answering the "when do you need to write unit tests". Because, if you unit-test everything you end up writing order of magnitude more code for the tests, then you write for the actual project. While this sounds "safe", in actuality, this is neither feasible, nor reasonable.

I've came to conclusion that I will write unit tests only in response to a bug report, as in: I write a test that reproduces the bug => fix the bug => use my old test to illustrate that the bug is fixed => commit.

I use other tools for testing GUI, but this would usually go for CI, and less so for unit testing because unit tests are actually there to confirm that the code at all works, rather than to confirm some expected user experience.