Uncategorized

haxe.unit, the unit testing package bundled in Haxe std library

May 18th, 2013  |  Published in Uncategorized

Not sure if you knew, there has been a minimal basic unit testing package, haxe.unit, bundled in the Haxe std library, since Haxe 1.02! Although its functionality is minimal, but it is enough for most of the projects and being very target independent. I would definitely recommend it to any beginner of writing unit test.

The haxe.unit package consists of only 4 classes:

  • TestCase
  • TestResult
  • TestRunner
  • TestStatus

Most of the time we need to use only 2 of them: TestCase and TestRunner. We subclass TestCase and put the test functions as class methods, and then create a TestRunner object to run one or multiple TestCase instances. I usually create one class for each class I want to test and create one test method for each of the methods.

For example we want to test the StringTools class in the top-level package of the Haxe std library. Here we wrote the test function for 2 methods, endsWith and hex:

class TestStringTools extends haxe.unit.TestCase {
	public function testEndsWith():Void {
		this.assertTrue(StringTools.endsWith("abcd", "cd"));
		this.assertFalse(StringTools.endsWith("abcde", "cd"));
	}
 
	public function testHex():Void {
		this.assertEquals("FFFFFF", StringTools.hex(0xFFFFFF, 6));
		this.assertEquals("000000", StringTools.hex(0, 6));
	}
 
	static function main():Void {
		var runner = new haxe.unit.TestRunner();
		runner.add(new TestStringTools());
		var success = runner.run();
 
		#if sys
		Sys.exit(success ? 0 : 1);
		#end
	}
}

As illustrated above, to check the return values of the function calls, there are 3 methods come from the TestCase class we can make use of:

  • function assertTrue( b : Bool, ?c : PosInfos ) : Void;
  • function assertFalse( b : Bool, ?c : PosInfos ) : Void;
  • function assertEquals( expected : T, actual : T, ?c : PosInfos ) : Void;

They are self-explanatory. You may have noticed, they all accept an extra optional argument of type PosInfos, which is actually used for getting the method name, line number etc for printing the test result. We should simply ignore it and the compiler will automatically fill in the value.

Notice that the test methods have to be named with prefix “test”. We can create utility functions, without the “test” prefix, and they will be ignored by TestRunner.

To run the tests, we created a TestRunner in the main entry function. The main function can of course be put into another class, but since we’ve only one TestCase in this example, let’s just put it into our TestCase. When we call runner.run(), it will test all the TestCase objects that are added to the TestRunner, and immediately print the test result, which for our example, it would be:

Class: TestStringTools ..
OK 2 tests, 0 failed, 2 success

Lastly, based on the return value of runner.run(), which is “all tests success or not”, we exit the program properly as a best practice. It is used by many CI softwares, for example TravisCI, in order to get back the test result.

There exist more advanced unit testing frameworks, like munit and utest, but the structure and concept is somewhat similar. Anyway, writing unit test is easy and the benefit is huge: It will enables us to discover regression that may caused by refactoring, adding new features, changes in 3rd party library (or Haxe itself) as soon as possible. Let’s start doing it today if you haven’t!

Tags:

jQueryExtern 2.0.0-alpha.1

May 14th, 2013  |  Published in Uncategorized

It took longer than expected, but jQueryExtern for Haxe 2.0.0-alpha.1 was released to haxelib!

The cool parts:

  • Supports jQuery version 1.9.1/2.0.0! Note that 2.0.0 has the same API of 1.9.1, but removed support of IE 6,7,8.
  • jQueryExtern is now generated from the official jQuery documentation in xml format. It means it will be updated faster, more accurate in the future!
  • Fine grained configuration of the extern via… macros! e.g. Select specific jQuery support version, switching between the use of “$” or “jQuery” in generated code etc.
  • Macro based Plugin extern system! Writing jQuery plugin extern is much easier.

You can find out the details at the github wiki page.

Tags: ,

Setting up a Processing Android project in Eclipse

April 25th, 2013  |  Published in Uncategorized

Processing, Android, Eclipse

Processing is written in Java, and it plays very well with the Android platform. Every serious programmer knows that the Processing IDE is far from being a proper IDE, and the official Android IDE is Eclipse, so we better stick to Eclipse.

To setup a Processing Android project in Eclipse, follow these steps:

  1. Setup a normal Eclipse Android project, such that we can run a simple hello world with a blank activity, targeting Android API 10+.
  2. Download Processing 2.0+.
  3. Copy android-core.zip to the libs folder as android-core.jar inside our Eclipse Android project (Yes, rename to .jar).
    The location of android-core.zip is:

    • For Processing 2.0 beta 9 and above, after installing the Android mode from within the Processing IDE, Documents/Processing/modes/AndroidMode/android-core.zip.
    • For Processing 2.0 beta 8 and below, inside the Processing folder, modes/android/android-core.zip. For Mac, the Processing folder can be found by right-clicking Processing.app, show package contents, /Contents/Resources/Java.
  4. Right-click the Eclipse Android project, properties. Choose Java Build Path, under the Libraries tab, click Add JARs… button. Choose the android-core.jar we’ve copied in previous step.
  5. Modify the MainActivity class such that it extends processing.core.PApplet instead of android.app.Activity:
    package net.onthewings.android; //the package of MainActivity
     
    import processing.core.*;
     
    public class MainActivity extends PApplet { //PApplet in fact extends android.app.Activity
        public void setup() {
        	/*...*/
        }
     
        public void draw() {
        	/*...*/
        }
    }
  6. Run the project and you should see a blank full screen app :)

Notice that it is not even necessary to use additional Eclipse plug-in like proclipsing. By coding in plain Java, we can mix the Processing drawing API with the Android API easily. Additional Processing Android details can be found at http://wiki.processing.org/w/Android.

Tags: , ,