what do I know

So in my search for mock object libraries, I continue to run into frustration with explicit typing in ActionScript 3. I did some searching and found a really great mock object library called mock-as3. It’s an expectation based library, in its early stages, but surprisingly featured and intuitive. Here are some usage examples from the author.

I’ve been writing code in ActionScript using explicit types, like most everyone I know who uses AS3, so mock-as3 out of the box won’t meet my needs. If I wanted to begin using interface classes and stubbing out my mocks (as mentioned in the examples) I could, but I won’t; the author even comments that it is extremely tedious to do and doesn’t necessarily advocate it. He hopes to have features in future versions of the library available to handle this but for now they are not available. In general, implementing interfaces for all classes that I’d like to mock is something I don’t agree with in any language. I’m a believer that refactoring your code will make a use case for the use of a programmatic interface over time; there are explicit cases where they are useful, but in the case of mocking, I’m not a big fan.

In any case, I did some thinking and wondered if there was a way to convert an object to a different type at runtime. I figured it’d take some bytecode manipulation, but I’m new to the game, so others much have thought about this already I assumed. Sure enough, I found an implementation by Darron Schall called ObjectTranslator which will convert an object’s type at run-time. I ran through some basic examples and everything worked as expected, so I thought, why not try to convert Mock, which is the class used to mock an object, to the class type passed in at instantiation? The implementation of ObjectTranslator just switches a byte for the new class type and directly copies the bytes of the object into a new byte stream. Worth a shot right?

In mock-as3’s implementation Mock is a subclass of everyone’s favorite class, Proxy. I did a basic test creating an expectation with the same name as the method in my class I wanted to mock and then used ObjectTranslator to convert the mock’s type. I then passed the typed mock to something to consume it and test to see if my expectations return value was given. Below is a the code I wrote:

1
2
3
4
5
6
7
8
9
10
11

var mock : Mock = new Mock(new MyClass());
trace(describeType(mock));
 
mock.method("method1").returns("PASS!");
trace(mock.method1());
 
var newMock : MyClass = ObjectTranslator.objectToInstance(mock, MyClass);
trace(describeType(newMock));
 
var typedUsage : UsageClass = new UsageClass(newMock);
trace(typedUsage.method1() == "PASS!");

Everything works except the final call to trace() which shows false because the value being returned is “FAIL!”, which is the default value for the method in the class declaration. I thought, well maybe I can add functionality to Mock where on each call to method() or property() I will create a property on the mock with the same name of the property passed in and point it to callProperty or getProperty from Proxy. Mock is declared dynamic after all. I gave it a whirl but no luck, I’m guessing there is something special done with Proxy that when I used ObjectTranslator, didn’t come over. There were also some properties used by Mock that didn’t come over because they were not part of the new type, specifically expectations. Since mock-as3 uses its internal reference to expectations I was hoping I would get this for free, but it didn’t work out from what I can tell. Without a way to eval() the code necessary to create a method signature matching the existing signature in the class declaration, I’m pretty much stumped.

If anyone has any suggestions, I’m all for it, but I kinda threw up my hands and called it a day. The more I play with ActionScript 3, the more it feels like the Flex community is going to have to produce things equivalent to CGLib to do anything flexible with ActionScript3 that is still type-safe (e.g. - mocks, AOP, etc). It sounds like from a thread on FlexCoders that the community really wants a Proxy#newProxyInstance method, so hopefully this will make Proxy a little more useful. I’m not sure, however, if they want to be able to instantiate Proxy at run-time or be able to instantiate a formal target property from Proxy of the target’s type. I’m hoping for the latter, but I’m still new to AS3, so who knows. Back to stubs …

So I’ve started my new job and I’m working with Flex and ActionScript 3. I was tasked with throwing together a couple classes and there respective unit tests this week. The classes don’t integrate with any external resources and mostly do pass through except for some cross cutting concerns (e.g. - logging, security, etc). I figured writing my tests would be pretty straight forward: throw together the appropriate test cases and in each mock out any dependencies.

Now when I think about a language I try to put it into the context of other languages I’ve had experience with, identify differences in language elements, and work from there. With respect to ActionScript, I tended to problem solve in the context of JavaScript since they are both based on ECMAScript, but I’ve run into some frustrations along the way.

To mock out an object in a test using JavaScript I’d typically write something like:

1
2
3
4
5

var dependency = new MyDependency();
dependency.methodToMock = function () { return true; };
 
var obj = new MyClass(dependency);
assertTrue(obj.passThroughMethodUsingMockThatICreated());

or if I wanted to mock out objects being instantiated by a dependency that I couldn’t inject:

1
2
3
4

MyDependency.prototype.methodToMock = function () { return true; };
 
var obj = new MyClass();
assertTrue(obj.passThroughMethodUsingMockThatIDidntCreate());

In ActionScript, assuming that MyDependecy is declared in an ActionScript class, the first and second approach I used in the above will not work. I did some reading on the Flex 3 livedocs and found out that the culprit was the traits object that was introduced in AS3. To abridge, the traits object is a copy of all applicable properties from parent classes and defined properties in the current class that need to be available at run-time to help reduce the performance hit of walking the prototype chain previously used for inheritance. The traits object is an internal mechanism which is not accessible by the developer. Prototype-base inheritance is still available, but falls secondary to traits. Awesome.

So unless I declare the methods of my class as members of the prototype for the class, I can’t manipulate them at run-time. So instead of the following:

1
2
3
4
5

public class MyDependency {
   public function methodToMock() : Boolean {
      ...
   }
}

I’d have to write:

1
2
3
4
5

public class MyDependency {
   prototype.methodToMock = function() : Boolean {
      ...
   }
}

So now I’ve got methodToMock available in a data structure I can mess with at run-time. I still, however, can’t accomplish what I did in JavaScript unless I add the keyword dynamic to the class declaration (as below) or remove the “strict” flag from the compiler:

1
2
3
4
5

public dynamic class MyDependency {
   prototype.methodToMock = function() : Boolean {
      ...
   }
}

Now I can manipulate the object and its class’ prototype the way I would in JavaScript. It irks me a bit that performance was the driving force for all of this hoopla, but I’m just an application developer, so I won’t pretend to understand all of the motivations for these decisions.

As another alternative, I thought about just using Object for all of my mocks, but I quickly dismissed the option since we’re using the explicit typing with ActionScript, as I suspect most are since its promoted for its performance boost. I also looked into using the Proxy class as a run-time solution, but alas it can’t be instantiated, only extended; this would mean writing class declarations for every mock I wanted to create, which seems kinda silly, and I still would have to deal with the explicit typing issue. On a side note, it would have been nice if Proxy had the option to be instantiated with the object it’s proxying as a constructor argument, mimic the type passed as the argument, and allow run-time manipulation. No idea if this is feasible though, so I’ll count it as a pipe dream for now. In any case, from my experience mocks are intended to be used within a context and disposable for the purpose of testing; why would I write anything more than inline code to utilize mock objects?

In the end, I’m probably going to be making end-to-end tests using stubs for the classes I want to test. Once we have some time to evaluate mock object libraries for ActionScript, I’ll probably start digging again for more answers. We’ll eventually need something to help us with expectation-based testing anyway, so a library will be the way to go. Hopefully I’ll end up finding something more like Mocha or Moq than JMock, although I think the opposite may be true.

There are language elements in ActionScript that I’m extremely grateful to have at my disposal (e.g. - events, properties, functions, etc). A few quirks exist though (e.g. - object/class manipulation at runtime and reflection) that still get me when I try to think about ActionScript in the context of JavaScript. Going forward I think I’m going to switch gears and solve problems more as I would a Java/C# developer than a JavaScript developer, favoring the use of libraries over the language features to get every day tasks done. I like ActionScript, but what good would a blog be if I couldn’t complain.

NOTE: I can’t take credit for the tagline, some Flex developers I know have begun to adopt it and I borrowed it from Dan.

… and the dog loses. We may owe Ptosis an apology, we didn’t know what they meant by puppy cut.

Today was the last day of the 4th job in my career. Over the last few years, mainly due to relocation, I’ve chosen to change jobs quite a few times. My decision to leave my latest employer was probably one of the toughest decisions I’ve had to make in my career however. Let me provide a little back story.

I started working for my last employer roughly 7 months ago. Previously I was working for a large, privately held timeshare company and was commuting anywhere from 2-4 hours a day from the coast into West Orlando. I was so eager to work closer to home, I decided to take a risk and accept an offer at a company I knew needed a lot of ground work to get to a point where they could be productive in terms of development. I’ve based my career on getting development teams organized and productive so this opportunity seemed like a good fit for me. Without getting into too much detail, over a few months I realized that I was working for a manager who was obsessed with playing political games and too proud to admit he had ever made a mistake. As it turned out, I wasn’t the only employee who had an issue with my manager, and after a year or so of service, my manager and the company decided to part ways. With our previous manager out of the way, things really started to look up, our opinions were heard and we were finally given the opportunity to be productive. The job had finally become what I had expected it to be after almost 6 months time.

Before my manager hit the road, I started to look for another job with the expectation that my manager would never leave the company; from my perspective he seemed pretty well seeded. I got an offer for a great opportunity to work with Max again in a job with some great technical challenges. The offer came before my boss was out of the picture however. I found myself faced with the choice of staying onboard with a shop that finally had its roadblocks removed or move onto a new opportunity in an area that really interested me. What made this decision even harder was the fact that both shops have a great teams behind them. Some may say it’s a good problem to have, but it’s wasn’t easy for me.

In the end I decided to go with a new opportunity for the potential growth that it will bring to my career. I’m hoping to make this new job a long term position and am really looking forward to the challenges it will bring. That being said, I leave an amazing team and a new and effective manager. Anyone who they find to replace me will be fortunate to work with such a great staff and for a company with so much potential on the web. I wish them nothing but the best!

As for my new team, see you on Monday. I look forward to finding new ways to fail you all