Taming and trimming FlexUnit async tests
I don't have time to update the HOWTOs associated with this before I end my day at the computer, but I had an ah ha! moment this evening with regard to getting FlexUnit to play nicely with RemoteObject against a PyAMF server.
Changelogs: ah ha moment, refinement and abstraction.
Files: the new test, the new class.
Some observations, where I use terminology loosely:
ActionScript looks superficially like Java, which is a language that I haven't used a lot, but that I've glanced at enough to notice certain patterns.
ActionScript is actually more like JavaScript, but has enough static typing to make it easy to follow Java idioms.
FlexUnit/RemoteObject samples that I've studied seem to define callback functions for asynchronous tests outside of the test case. This is unnecessary, in my opinion, and makes the test case much less readable.
If you look at the example test above, there are five variable assignments, then a call, that comprise the entirety of the test:
- Line 41-42: Trigger an asynchronous operation that will produce a value object that we want to inspect.
- Lines 43-48: Define a function to compare the state of that object with our expectations of it.
- Lines 49-54: Boilerplate to connect the two together.
To me, this is a clearer way of defining tests. I hope to refine this even further by turning item 3 above into one or two lines of code.
To get to that point, my plan is to develop an API for deleting the database collection (if allowed by the server), create an empty named database, list database names, and delete a named database. That should give me enough code to figure out where the lines of fissure are to reduce that boilerplate.
Does anyone else out there know of more FlexUnit tricks? :)
Tags: actionscript, flash, flex, flexunit, pyamf, Python, RemoteObject, remoting, Schevo, schevoflex, testing