Test Infected...

Just in case...

2006-10-27T17:33:00.000-07:00

...anyone is still linked to this blog, I have moved to http://www.asserttrue.com where Ali Mills and I post about a variety of topics (including asunit). If I ever get time, I might move these posts over to that database, but for now, please update your links as this one won't be getting posted on anytime soon.

Continuous Integration with AsUnit?

2005-11-28T20:37:00.000-08:00

We received another excellent question today on the asunit-users list. This one came from Ian Tyrell.

I believe he wanted to know if AsUnit could be coerced to play nicely with other mainstream continuous integration tools. Specifically, he asked, "...what would be needed to take things a step further and automatically run/evaluate the tests. What’s stopped me in the past is the use of LocalConnection between tests and TestUI"...

Well Ian, we haven't really brought AsUnit 2.x to that point yet, but AsUnit 3.x is pretty much ready to go. Fortunately, there is still hope for ActionScript 2.0 developers!

Many thanks to some genius at Macromedia, there is a little-known feature of the Flash Debug Player that allows it to output errors and trace statements to a text file - anywhere on your system.

Following are some articles that extoll the virtues of this feature in depth:

Greg Wygonik
actionscript.org
livedocs.macromedia.com

Once this has been properly configured, you can then write or implement whatever scripts you want to watch changes made to that file, and when some knucklehead (like me) checks in broken code, an email can be sent to the entire team with the failure log and even a list of the most recent version control checkins.

I haven't actually set up a system like this yet, because so far, Ali and I have been able to work pretty much by ourselves over the past couple of years, and if someone checks in broken code - it's usually pretty easy to guess who it was, and - I'm not too hard to find!

As it stands, it should be pretty easy to dig into the sources associated with AsUnit 2.x and make it "trace" the output rather than (or in addition to) sending it to the TextField that it currently sends to.

Ultimately, if you can get the AsUnit UI to send the contents of the TextField to a trace statement instead of the TextField, you should be able to pretty easily set up some service to watch that .log file and provide whatever embarrasing notification you deem necessary...

Please let me know if you get this working, as I would love to update the sources with your changes so that others can also benefit.

Good Luck,

Luke Bayes
www.asunit.org

Testing Asynchronous Functionality...

2005-11-25T16:41:00.000-08:00

I encountered an excellent question today on the asunit-users mailing list. AliasRob asked:

>> Just wondering if anyone has had any interesting stories or
>> experiences regarding unit testing asynchronous functions, such as
>> loading a .swf, or waiting for a database or remoting call to return.
>> I'm wondering if there's a particular strategy that's becoming
>> popular.

The testing of asynchronous functionality has been the subject of deliberation by many folks that are smarter and more experienced than I. Following, I'll do my best to describe this problem and it's potential solutions as I have understood them from these other people...

The Problem:
You have a bit of functionality that does not execute in a single thread of execution that you would like to test and verify.

The Information:
There are some fundamental tidbits related to Unit Testing that ought to receive some consideration before we go much further.

There should be no dependency from one test method to another. Test methods should be decoupled.

There should be no dependency from one test case to another. Test cases should be decoupled.

As with applications, test fixtures should attempt, at all times, to avoid code duplication and all other code smells (as outlined in "Refactoring").

A Unit Test should be designed to test the smallest bit of functionality, and nothing else.

A complete application test fixture should execute as quickly as possible in order to ensure that we continue to run it.

The setUp and tearDown methods of the abstract TestCase are overridden and implemented to perform (and clean up from) the complete configuration that needs to be in place for each test method in a test case. These methods will be executed exactly one time before and after (respectively) calls to each method whose declaration matches the expression "public function test*".

One can use Mock objects for a number of reasons, one of which is as a stub or faux representation of an actually-networked resource.

Test cases should never (the emphasis here is mine, most books I have read never say never) require access to the internet in order to successfully execute.

The Solution:
With all that said, the answer to your question is that it depends on exactly what you're testing. If you're attempting to test the backend of a system using it's client, you should stop. The server side of a system should be unit tested independently of any client software. These two halves of an application should not ever be tightly-coupled. The developer or developers responsible for the server should write unit tests that ensure the server is working as expected in whatever language and using whatever technology the server was written in. Likewise, the developers responsible for the client should test its features independently.

How does one test the interface between these two systems?

That's an excellent question. It is done by building a "mock" or "stub" of the server that doesn't actually connect to anything, but instead returns consistent, known results to API queries.

Then, the server developer can build herself a "mock" or "stub" client that behaves exactly the same way in order to test her side of the connection.

Neither of these tests should require network connections.

The biggest issue with this approach occurs if your server has an extensive, large set of complicated APIs. I have often found that the server side of a system should usually have only a small handful of interface methods, and when I have encountered systems that actually did have an extensive interface, it seems that it was usually a code smell where we should have been reading the book, "Enterprise Integration Patterns", instead of over-engineering the connection between our efforts.

In another scenario, you may want to test some piece of functionality like an "xml parser" of sorts or some such other feature that is much easier to test if the data does not have to be managed in ActionScript.

For example, the following is a hideous thing to uncover and later have to manage:


private function getData():XML {
    var str:String = "";
    str += "<Application id='foo'>";
    str += " <child id='bar' />";
    str += "</Application>";

    return new XML(str);
}

For this use case, we have added full support for a truly asynchronous test case. Following is an example concrete TestCase that will execute asynchronously.

The first method called by the TestCase constructor is the "run()" method. In the following example, we override run(), and instead of doing other work in the override, we simply create and request an XML document that resides in our test folders next to the test case in question. In this case, we are using the AsUnit-provided TestCaseXml class which will, upon load completion, call "onXmlLoaded" on whatever object was passed as the second argument of it's constructor.

You'll notice that in that handler, we finally call super.run(). This begins execution of the test case only after a successful load of the xml document. This process can be similarly implemented to load and verify external assets such as swfs or images as well.


import org.yourdomain.data.XmlParser;
import com.asunit.framework.*;

class org.lifebin.data.XmlParserTest extends TestCase {
    private var className:String = "org.lifebin.data.XmlParserTest";
    private var parser:XmlParser;
    private var xmlData:TestCaseXml;
    private var xmlPath:String = "com/yourdomain/data/XmlParserData.xml";

    // This method begins execution of the abstract TestCase
    // We are overriding it here to effectively pause that execution
    // until our xml data is loaded.
    public function run():Void {
        xmlData = new XmlTransport(xmlPath, this);
    }

    public function onXmlLoaded(data:XMLNode):Void {
        super.run();
    }

    public function setUp():Void {
        parser = new XmlParser(xmlData.cloneNode(true));

    }

    public function tearDown():Void {
        delete parser;
    }

    public function testInstantiated():Void {
        assertTrue("XmlParser instantiated", parser instanceof XmlParser);
    }
 
    public function testParser():Void {
        assertTrue(false); // failing test
    }
}

In closing, I just want to make the point that the asynchronous test case is really only valuable when we want to store "configuration" data in a more easily manageable form. EG, if I have an image parser in ActionScript 3 that will examine each pixel of an image as a ByteArray, it is much easier to load an external, known image than it is to write out some 300k ByteArray in a setUp method. Similarly, it is often easier to test various Xml parsing implementations by actually using a separate xml example document. Keep in mind that the test for these parsers are not intended to also test the "network" or the "server".

One should also note that in this example setUp method, we use the "cloneNode" method of the flash XML object. We also pass in "true" as an argument. This performs a "deep clone" on the loaded XML data structure so that we have a clean copy of the data exactly as it was loaded for each testMethod that is executed.

Thanks,

Luke Bayes
www.asunit.org

AsUnit Meets XULRunner!

2005-09-07T16:25:00.000-07:00

I've been researching XUL for the past few weeks and couldn't seem to answer all of the questions that keep coming to mind. I figured the only way to get it sorted out, was to build something in it, but I couldn't think of something that would be worthwhile and yet easy enough...

Enter "Create Class"

Since it's inception, I have had more than a few personal complaints about our implementation of Create Class. Thankfully, other folks have been really polite about it's shortcomings. I made excuses for it related to the limited implementation of XUL that is included with the Flash MX 2004 IDE (Among other things, It ONLY has XUL 'Dialog', NOT XUL 'Window')...

During recent months, I have become a sort of "Editor-Gigolo" and keep hopping from one to another in a desparate search for the "most amazing editor EVER".

Some environments that I have checked out include:

PrimalScript

Flash MX 2004 IDE (url gone?)

Flash 8 IDE

Eclipse with FDT

Eclipse with ASDT

Emacs

TextPad w/MTASC

So far, each environment has some benefits and some drawbacks and I'm not 100% excited about any of them yet. I think that Emacs is the most promising, but it has a pretty high learning curve and causes some pain in my wrists with all the complex and repetitive key combinations! Right now, I'm settling into TextPad because it's fast, easy to launch from CygWin and it's really customizable.

Basically, in all this moving around, I have been dreaming about the day when AsUnit (and especially Create Class/Build Test Suites/Create Test Case) will work for me no matter what environment I'm using, and especially without regard to my operating system. (Even, dare I say, LINUX?!)

As it turned out, I kind of lost my mind over the labor day weekend and started rebuilding the functionality found in the AsUnit Create Class command and AsUnit UI Panel as a standalone XULRunner application. I thought I would just get a "beginning" in place and wound up building the whole damn thing!

I should probably hold off on releasing this until I make time to write an installer and some docs or something, but I just CAN'T WAIT!

So, without further rambling - if you're interested in the coolest utility to hit Flash development (in the past hour or so at least) - follow these (sort of) simple steps:

Download the zipped files AsUnit 2.7 (alpha)

Download the latest build of XULRunner from Mozilla.

Unzip the createclass.zip file to somewhere on your system that won't change.

Copy the com folder out of the unpacked classpath folder and put it into some directory that your compiler references. This should be either some place where you tell MTASC to look or if you're using the Flash IDE on windows, it will be somewhere like:
C:\Documents and Settings\lbayes\Local Settings\Application Data\Macromedia\Flash MX 2004\en\Configuration\Classes

Unzip the files you downloaded from Mozilla to some place that won't change. I put mine into:
C:\Program Files\Mozilla\XulRunner

Update your system PATH variable to include the location of xulrunner.exe
On windows, this can be done by:
- Using Windows Explorer, go to the folder that contains xulrunner.exe
- Select the text that appears in the address/location field
- Copy it to your clip board
- Right-Click My Computer
- Choose properties
- Select the Advanced tab
- Click Environment Variables
- In the System Variables, choose the one that says, "Path"
- Click the edit button
- In the Variable Value field, go all the way to the right, add a semi-colon ";"
- Paste the contents of your clip board into this field
- Keep choosing OK until the panels all go away

Open up a command prompt (Cygwin if you have it)

Navigate to the folder where you unzipped createclass.zip, step into the xulCreateClass folder

Enter:

xulrunner application.ini

Start Playing!

Some things you'll definitely want to try:

Create or choose a working directory

Add class paths to the UI

Choose "Create Test Case"

Choose "Make Class Serializable"

Choose "Add __Packages Prefix"

Select or Deselect "Show only interfaces"

Keep opening the files that it creates!

DEFINITELY choose "Private w/Singleton" in the modifiers section!

Once you have some class paths in there, you should be able to click "Choose" next to "SuperClass" and you should see every .as class that's available in your working directory and your classpath(s)... This also applies to the "Add" button for interfaces. Interfaces should be shown in blue in both of these lists!

Disclaimer(s) and random tidbits:

This is barely ALPHA quality software! I hacked this out in three days as my first effort in XUL. Please don't set C:\ or your Desktop as the source folder! PLEASE create a new, empty folder and use that as your source folder.

I have not run this even one time on a mac or linux, if you have either of these platforms, please let me know if it works!

This should create error-free code for MTASC and the Flash IDE compiler(s), but the only templates that are current available are for MTASC compliance - since it's so much stricter...

I *KNOW* that someone out there has (or wants to gain) experience building Firefox / Mozilla extensions, this is a perfect opportunity for you to contribute to an open source project! We're in desparate need of a good, solid XPI (Cross Platform Installer) so that when this is released, users can install it with a single click... Wanna help? Sign up to the asunit-users mailing list and let us know?

I included anonymous CVS files in this release, so that as we iterate on the functionality, you can use CVS to perform instant updates to your local builds. This is kind of risky, so only do this if you know what you're doing. We'll be careful not to check in broken stuff to the head revision from this point forward...

PLEASE let me know what you think of this by posting to the AsUnit mailing list...

Emacs?!

2005-07-09T18:22:00.000-07:00

I have this growing stack of books on my night stand. I tend to read some of a book, pick up another and eventually return to the original one. This can continue for as many as 10 or 15 books and 2 or 3 months at a time. My night stand is obviously quite a mess! It occurred to me that someone out there might be interested in at least some of the things I'm reading, so I put together my second book list that you can find here... This is the list of books that are currently on my night stand.

Now on to the actual point of this entry - I started reading The Pragmatic Programmer last week. I'm about half-way through and had to stop in order to implement at least some of what it says before going any further. Ali and I dropped into Stacey's on Friday afternoon and picked up a pile of books that should help us on our way. Among many other compelling and wise statements, the authors (Andrew Hunt and David Thomas) make a significant and effective argument that I hadn't really seen so clearly before.

The Power of Plain Text

They make the case (extremely effectively for me at least) that we should keep our most important data NOT in secretive, proprietary, volatile, incompatible, binary formats, but instead - in human-readable, cross-platform, version-able, merge-able Plain text files. It's OK to compile this plain text into more efficient binary formats for specific purposes (like network transmission for example), but it's unwise to store our most critical information using transient and volatile means such as Micorosoft Word documents and Excel Spreadsheets. It's important to note that the authors do not come out and say anything about these particular file formats, and I'm eager to point out that even Microsoft itself has finally embraced the wisdom in this idea...

They cite the following primary reasons for using Plain Text:

Insurance against Obsolescence: Unlike binary files, for as long as that file exists, you can use any standard tool to parse it and unlock it's secrets.

Leverage: Just about every tool available in computing can operate on Plain Text. Within this argument, these guys proceeded to describe some ancient (1980's) and yet stunningly efficient and powerful tools that I'm frankly ashamed to not be intimately familiar with. (for example: Emacs, Sed and Awk)

Easier Testing: It's much simpler to verify and validate inputs and outputs if a system works with Plain Text rather than hidden binary formats. This argument really goes to the core of my problems with Flash Remoting.

Finally, as a result of reading The Pragmatic Programmer, I wound up getting all involved in learning Emacs (I'm using it right now to create this blog entry). I picked up Learning GNU Emacs from O'Reilly and haven't been able to put it down. I am seriously considering this as my primary editor for all-things-text. Yes - even ActionScript, Java and maybe even my address book, calendar, journal, blog and email?!. I'll definitely report back as I learn more on the subject. I'm a little concerned that I might be getting too excited, but my initial research is extremely encouraging. It seems that some very focused and very smart people have been refining this tool as a development platform since 1984. I didn't know this, but apparently Emacs was originally written and continues to be led by RMS himself. ;-)

XUL Runner?!

2005-07-04T16:03:00.000-07:00

A couple of weeks ago (thanks to my handy Firefox t-shirt) I ran into a super-smart young guy on BART.

http://weblogs.mozillazine.org/josh/
http://josh.trancesoftware.com/

I ended up hanging out this weekend with him and a friend of his named Alex. We wound up talking about the future of GUI application deployment (Since the topic pretty much consumes every waking moment for me these days). He and his friend both are doing some work this summer in Mountain View for the Mozilla Foundation and turned me on to something that's pretty damn exciting.

I had this idea a couple of weeks ago - what if I could wrap up the XUL foundation classes, download, install and instantiate the Flash Player for whatever platform the user was on, and ultimately deploy a single, distributed application that will run from the web within whatever browser you have, but also offer (with roughly identical code) a downloadable, installable, more feature-rich, occasionally-connected version of that application? What if we could combine the in-browser ubiquity of the Flash Platform, with the small footprint and easy installation of the desktop XUL platform? Could this possibly work? Ali and I have talked about it a bit and neither of us really have the skills to be ripping out C++ code from the Mozilla project, but we were preparing to try anyway!

As it turns out - Josh and Alex turned me on to XULRunner, a thin, installable implementation of the XUL runtime without Firefox, Mozilla or any other specific application. Of course it's not really released yet, but it sounds like we'll be able to distribute applications as singular binaries or bundles on any platform at some point this summer. For now, thanks to the nature of open source - we can download nightly builds and learn about this thing!

Here's how to get started:

1) Get the exe:
http://ftp.mozilla.org/pub/mozilla.org/xulrunner/nightly/latest-trunk/

2) Put it somewhere you'll remember... I unzipped into:
C:/Program Files/Mozilla XULRunner/

3) Update your path so that xulrunner refers to this location.

4) Download the simple-browser example:
http://friedfish.homeip.net/~darinf/xulrunner/mybrowser.html

5) From wherever you unzip it, open a command prompt and run:
xulrunner application.ini

Here are a few other links that I found useful:
http://wiki.mozilla.org/XUL:Xul_Runner

http://blogs.acceleration.net/ryan/archive/2005/05/06/1073.aspx

http://developer-test.mozilla.org/en/docs/XULRunner

http://www.mozillazine.org/talkback.html?article=6421

2005-06-13T21:53:00.000-07:00

I was just doing some research for what seemed like a pretty simple, benign, blog posting, and wound up spending two hours following links on Ward Cunningham's wiki...

I figure it might be helpful to share some of the highlights of my scouring.

Along with a few other XP terms, the term "Unit Test" is in the process of "officially" being changed to "Programmer Test" apparently in an effort to avoid continuing confrontations with the very powerful and demanding Quality Assurance Industrial Complex.

Apparently, shockingly, I'm not the first person to hope for, look for and dream about the most amazing programming language "ever"...

(That's three different links you should click on)

I found out that the thing I tend to do when nothing logical seems to be working in Flash, actually has a name.

I also learned that if you're using blogger.com, and you're editing a blog, CTRL+S actually saves AND publishes the page you're editing - which subsequently sends an email to anyone that is subscribed to your blog.

Sweet.

2005-06-07T21:26:00.000-07:00

Just wanted to give a heads up...

Ali and I had a talk with Robert Penner last Friday to discuss his involvement in ongoing AsUnit development.

As it turned out, he had quite a few really GREAT ideas about how AsUnit could be improved.

One of them was that we could batch our Local Connection transmissions so that the UI would be more responsive.

I was promptly up until the wee hours last night trying to get it to work. Knowing what I know about the implementation, I figured that it would be a pretty easy addition...

As it turned out, I was able to get some small tests working, but as soon as I ran some of our bigger applications, none of the Tests were being received by the server. There was no call to onStatus, no obvious reason for the failure, no notification whatsoever. Eventually, (around 1:30am or so) I figured that I probably shouldn't be coding and drinking and figured I must be doing something stupid!

This morning, I caught a surprising conversation on the osflash list - they were talking about how the Local Connection object has a 40k data limit! What?!

So I checked the implementation and if I put a 100 assertion limit on the batches, everything worked fine - even on the big builds.

So -

I dropped a build on AsUnit that has a 100 assertion batch size, but this is kind of arbitrary - especially considering that folks could put just about any size of string message into each assertion and even more so because I usually don't put anything in the message field.

I now want to put together a build of LocalConnClient and LocalConnServer that has some kind of handshake mechanism, so that any tranmission also includes confirmation of receipt. If the server doesn't confirm, the client will throw some kind of error. We can then handle this error in AsUnit by cutting the batch size down a bit, and retrying the request.

I figured folks ought to know about this - since it seems to be pretty important if you're building an app that relies on Local Connection...

2005-05-28T13:15:00.000-07:00

I received a question about Flash Remoting and thought maybe my answer could be helpful for some other folks out there.

>> I'm looking into a job that would require working with AMFPHP. Has anyone dealt with it before?

I have to confess that I have never used AMFPHP, but I have used Open AMF, and Macromedia Flash Remoting for both Java and Cold Fusion. I have also worked with Carbon Five's ASTranslator, which can make working with Remoting at least a little less painful.

My opinions about Remoting have softened quite a bit over the past year or so, but remain nonetheless. Each objection that I have can be resolved one way or another, but I think one should be aware of these objections and their solutions before engaging in a Remoting project, regardless of the particular Remoting technology.

Tight Coupling: Remoting provides a very tight (and hidden) coupling between the client and the server. You can overcome this by creating an ActionScript mock implementation of your server that returns ActionScript objects just as if they were coming from the back-end. Your server developers need to also create a mock client. I think this is quite a lot of work and very difficult to keep in sync with changing APIs. This problem is a big deal. This problem means that unless you build the mock client and mock server, you can't really test your communication code until both the client and server are completely working. Additionally, there will come a day - that will probably turn into a week, when you have a server developer sitting next to you and the two of you have to struggle through "integration" just to get this layer resolved. It also makes it difficult to tell where a problem is. Is the problem on the server? Is the problem on the client? Is the problem in the mock server or mock client? Is the problem a bug in Macromedia's Remoting ActionScript code? How about the server side Remoting code? Don't forget that if you don't build a complete mock client and complete mock server, you will only be able to develop your client and server code while connected to the Internet - or at least while connected to one another. For example, you'll need a fully functional, CURRENT, configured server implementation on your client development machine. This will have to be kept in sync with updates as the server developers make them. This has additional development overhead as you learn the back-end build process. It also has additional performance overhead while you compile and test your client code.

Another issue with tight coupling is that you will have created server and client implementations that will only work with one another. You cannot take that PHP Remoting service and quickly build an HTML client for it. You are locked into Flash/Remoting/Your Server (FRYS!?). What if Adobe decides to bundle the Yahoo Toolbar, Acrobat Reader and some other unwanted junk into the Flash Player distribution? Your client might decide to use AJAX at that point. Now they're going to have to rebuild both halves of their application - not just the client code.

Debugging: There is a Remoting Debugger, but it's kind of useless in my experience, especially if you're transmitting large data sets, which ironically is the only reason to use Remoting in the first place!

Single Callback: Remoting provides a single callback for each remote method. This can cause a problem if your application calls the same method multiple times before the first result is returned. There is no guarantee that the results will be returned in order, and in fact they rarely are. Creation of additional gateways is fairly expensive in terms of performance, thanks to the NetService classes. There are some other workarounds like client-side connection pooling.

The only good justification that I have heard for Remoting is that it compresses your data into *much* smaller packets. I believe that if you really need to do this, you're probably doing something wrong in your data design. Your views will probably choke on such large record sets anyway. Have you considered paginated records? How about summary results that contain unique IDs, which then let you download single, client-requested record details? Consider how other people with extremely large data sets handle it. How does Google get terrabytes of data into a simple HTML web client? Do they just zip it all up and send it downstream for each request?

With the criticism out of the way, I do know some very smart people who use Remoting and they feel it's an excellent way to get data into and out of Flash. Based on discussions with them, it became clear to me that if you're experienced, have a fair amount of control over the back-end and don't mind building a mock server and mock client, it is certainly possible to build a respectable Flash application that uses some form of Remoting.

The primary alternative to Remoting is XML, which is extremely easy and increasingly efficient to parse in Flash, especially when using the Visitor pattern. XML inherently brings the following benefits:

Easier/Faster Debugging: Because it is human readable, XML gives us the ability to instantly recognize where a problem exists in the communication layer of an application.

Promotes Loose Coupling: It more effectively decouples the server from the client. We have options available (like XSLT) if there is a minor change to the server and we don't want to change the client.

Verifiable Serialization: With XML, we can quickly see exactly what data is being used to create our objects and exactly what data is being sent from them. In contrast, Remoting serialization automates, and subsequently hides this information.

Simpler Mock Services: XML lets us build a local human-readable, easy-to-modify mock server that runs from the hard disk with no other installation dependencies. Server developers can also build very simple mock clients so that their applications can be built and tested independently.

Helps Prevent Miscommunication: It facilitates extremely clear communication about data formats between the front-end and back-end developers.

Easier to find Developers: It's MUCH easier to find someone who can read and write XML than it is to find someone who has experience with Remoting. This makes hiring and replacing both server and client developers a much less risky task.

You'll need it anyway: If the back-end has any sort of mass audience, your server developers will most certainly need to publish at least some subset of their APIs to XML. Is an RSS feed in the spec?

It's not going anywhere: XML is the foundation of the Semantic Web.

I think I've rambled on long enough for now. The bottom line is that I have used Remoting on a handful of projects and it was extremely painful for me. Despite those experiences, I have seriously considered using Remoting on the last two large projects that I've worked on. I am pretty sure that I'll use it at some point in the future, but I would offer a whole lot of caution before diving into a Remoting project. Whatever you do - in the words of the immortal Flavor Flav, "Don't, Don't, Don't believe the Hype!"

Luke Bayes
www.lukebayes.com
www.asunit.com

2004-12-08T17:40:00.000-08:00

I gave a presentation to the Design Patterns User Group tonight and here is a copy of my Handout:

Unit Testing in ActionScript 2.0 using AsUnit

Goals:
My Goals for this presentation are to convince you to:

Download AsUnit and contribute to it’s development in any capacity (As a User, a Tester, a Developer, Documenter, or especially as an advocate)

Learn more about Test-Driven Development

Learn more about Refactoring

Learn more about Object Oriented Programming

Problem:
The design and development of complex systems invariably results in unexpected, unforeseen problems and issues. These issues will always appear and are invariably discovered through some form of “Testing”. Testing comes in many forms, but I have encountered some combination or subset of the following in each project:

Developer Testing is when you check your own work as you build it by using the feature being built and seeing it work.

End User Testing is when your end users (usually pay for) and then discover all of your product failures.

Acceptance Testing is when someone else checks your work as it’s released according to a script or some well-defined series of steps against documented, expected results.

Unit Testing is a process by which we (the developers) test each small piece of our software automatically and instantly throughout it’s development.

Relevance:
For those of us that are designing, building or being held responsible for complex software systems, testing in some form is critical. Unit testing is unique because it gives us the following benefits as developers:

Helps design better systems *now* by forcing you (the developer) to think about your class from the perspective of it’s consumer.

Essential part of Refactoring (“Changing the Design of Existing Code”).

The only way to *grow* a complex or large system with confidence.

Enhances the legibility of self-documenting code.

Removes massive unwanted trace statement debris that clutter up the output window and usually obscure the currently relevant debugging info.

Puts zero testing code into the final product which creates a smaller delivered code base.

Gives us added confidence and pride in our delivered product.

Solution:
There are currently a small handful of Unit Testing Frameworks available for Flash Application development. We’ll be talking about AsUnit because it is arguably the most feature-rich, efficient, xUnit framework available for Macromedia Flash ActionScript 2.0 applications. Especially those that may be deployed to the Flash 6.x runtime environment.

Printed Resources:

Test-Driven Development: By Example by Kent Beck

Design Patterns by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides

Refactoring: Improving the Design of Existing Code by Martin Fowler

Refactoring to Patterns by Joshua Kerievsky

The Mythical Man-Month: Essays on Software Engineering by Frederick P. Brooks

Extreme Programming Explained: Embrace Change by Kent Beck

Online Resources:

www.asunit.com

www.junit.org

www.refactoring.com

www.xprogramming.com

www.extremeprogramming.org

2004-09-09T16:36:00.000-07:00

I had this problem...

My day to day ActionScript workflow is starting to look more and more like the process that I'm reading about in XP books.

Create a Failing Unit Test

Get the test to Pass as Simply as possible

Refactor

Repeat

In ActionScript, the refactoring part is a giant pain. Thanks to the major lack of a quality IDE.

I use Sapien PrimalScript to write code and it is truly the best ActionScript 2.0 editor available on the market today.

As long as you create a "PrimalScript Project File", it will provide code-hinting (PrimalSense) and auto-complete with menus that include MY custom classes and their public members. (*Also whatever is in your Macromedia/Classes directory)

The tough part comes in with regard to managing that Project File. I'm cruising along creating new classes and modifying existing ones. I feel like things are working out great. Then I need to bring my project file up to date so that PrimalSense works. This was kind of inconvenient, but tolerable, until I recently started trying to work with a "core" package of shared, abstract classes and then multiple other packages of concrete classes that in many cases extend the shared functionality.

This means that I suddenly needed to keep multiple project files "synched up" with a single "core" directory and current with regard to their own concrete classes. This process became clearly unmanageable in about 10 minutes.

ENTER JSFL!

So, I sat down and wrote a JSFL script that will:

Allow a user to point it at 1 to n directories

Search through them in order

Find each file that matches a certain expression

Create a single PrimalScript Project that displays all chosen directories as if they are all in the same place!

It's not quite fully complete yet, but it serves my needs. As an experiment I even pointed it at the Macromedia/Classes directory. This was a little bit time-consuming, but worked also.

For the short term, I'm going to post the mxp here for whomever wants to take a look but you should be warned of a few things:

This isn't production ready

This will not be here long

This is *not* open source code

This belongs to Ali Mills and I

This has a couple of bugs

Ultimately, we're planning on adding the following to a custom UI and selling it for $5 or $10 bucks:

User-driven Regular Expression for included/excluded files

User Selection of 1 to n directories

User Selection of Project File Name

Once we built this thing and got it working for PrimalScript, someone asked us for a similar utilty that would output a Flash Project File (FLP). Personally, I can't see the value in using the Flash IDE as a text editor, but who am I to criticize?

So we ported over what we had and added FLP output. This gets a little bit complicated because the Flash IDE does not respect that an "open" project file has changed, but we worked around that with some notifications to the Output Panel.

If you're tired of trying to keep your PrimalScript or Flash Project files in synch with your constantly-changing ActionScript packages, feel free to download this MXP and let me know what you think!

Thanks.

AsUnit Cross Platform Support Released!

2004-09-09T16:07:00.000-07:00

Ali and I finally got around to full cross-platform support in AsUnit!

We have released the .mxp installer and the source code on sourceforge.

Some features include:

Custom Unit Test Output Panel will provide instant feedback related to the status of your tests. This panel is accessible to the .swf file both locally in the Test Movie Player, and remotely from a .SWF running the browser.

Integration with Flash MX 2004 IDE Output Panel

Create Class Command will auto-create the Class in the package defined and an associated TestCase that has one passing test and one failing test.

Create Test Suites Command will recursively search for class files with the following name *Test.as and create TestSuites that instantiate them all.

External Debug Output that will allow you to view Test Output (using Sys.println("message");) even from .SWFs running outside the TestMovie player.

Simple .MXP installation/uninstallation using Macromedia Exchange file formats.

No Library or asset manipulation required on Flash Timelines

Open Source (LGPL License) so that you can fix whatever problems you perceive.

Integrates with Built-in ClassPath so that all newly created libraries are available to any files or projects that you are working on.

Immediately Available to all Existing Flash ActionScript 2.0 Projects

PrimalScript will provide code hinting for newly created custom classes.

Applications under test can be exported for the Flash 7 or Flash 6 player.

2004-09-09T15:17:00.000-07:00

We have announced the first weekly meeting of the "Design Patterns Study Group".

The Design Patterns Study Group is a semi-formal organization of professional application developers that are interested in a deeper comprehension of design patterns, refactoring, test-driven development and other Agile development processes.We will meet every Wednesday to present and discuss in detail a single design pattern. All pattern examples will be presented in Flash ActionScript 2.0 and proofed using AsUnit.

There should be more info on my website...