ActionScript: Just different enough to piss you off

Brian LeGros | October 19th, 2008 | programming  

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.

Diving back into Selenium and saving me some time

Brian LeGros | September 24th, 2008 | programming  

Over the years I’ve been using Selenium as my tool of choice for UI testing on the web. Recently, we’ve had the need to regression test a vendor web application due to some poor quality builds being produced. Based on past experience, it takes us about 40 hours of work to regression test the product UI by hand, including double checking for annoying copy changes that always seem to slip through. Today we finished the first chunk of a baseline set of tests that accounts for roughly 30% of our test plans. It took us about 150% of the time needed to do one regression test to get this first chunk done. Since we regression test regularly, we’re going to incrementally add more tests each time, getting into a habit of updating our Selenium test suites with the latest changes per build. With that said, let me just tell you this is probably one of the most detailed applications I’ve had to test with Selenium. Guess how long it takes to run our tests that don’t require some type of manual setup … less than 5 minutes. So we’ve taken a third of our tests that took about 10 hours to execute and reduced them to 5 minutes of watching the browser go nuts with all the typing and clicking. There is still work to be done manually that we will never escape (global system setup), but talk about saving time. No matter how much I use Selenium I never get tired of the benefit it provides in the long run.

So all though these stats are encouraging for management to hear, but what I really like about Selenium is how simple it is to create test suites. Don’t get me wrong though, there a few things that can cause hang-ups. Hacking out XPath statements is one that I face quite frequently. Consider a command in Selenium called verifySelectLabel which takes a locator (typically an XPath expression) to find the select box in the DOM and a pattern (typically a simplified regex) to match the text of the option currently selected in the select box. The Selenium IDE has a “Find…” button to help validate the XPath statement and some context menu options in the browser to help, but in most cases I always find myself messing around with the XPath statements. Recently, while playing around with Firebug (my favorite JavaScript swiss army knife) I noticed that under the HTML tab when right-clicking on a tag you get the option Copy XPath. Selenium’s XPath support is really robust and the Firebug’s syntax ports over flawlessly. I did notice that while running in IE I had to simplify the statements sometimes to get them to pass, but otherwise, it’s cut my recording time down considerably.

Another thing that always sucks up my time is when I have to hack together JavaScript to get data ready for a test (especially when it comes to dates). The storeEval command will execute a JavaScript snippet and take the result of the last line and put it into JS variable for later use. In the past I’d fire up a kind-of scribble pad HTML doc with some inline script and test my code, but this time around Firebug is all I needed. The Console tab gave me my own scribble pad with the added help of the Firebug console object. Another cool JavaScript helper I hadn’t used before was the user-extensions.js file, which is imported into the test runner giving you access to whatever JS you want to re-use. I found a pretty descent date API that I copy/pasted into this file making working with dates in my tests stupid simple. Finally, this is the first time I’ve tested a product that I didn’t help write and that was written using ASP.NET Web Forms. With the help of debug(), monitor(), and the Inspect tool in Firebug, I was able to find my way around the mess of scripts on the page very quickly. Even though the generated code wasn’t my favorite, I have to give credit to ASP.NET’s management of inputs; each input was generate with a unique ID which made testing incredibly easy.

Overall, it was great to get back into using Selenium and I’m really excited at the possibilities of starting to use Selenium Remote Control and Grid. The prospect of getting my unit testing framework (NUnit) into the picture will definitely help to complete and simplify the build process. What’s even cooler is that once we’ve put all the work into recording our tests in HTML, the Selenium IDE will translate them into C# so we don’t have to repeat ourselves. With new extensions for working with Flex, this tool’s potential continues to grow. If you’ve never tried out Selenium, definitely give it a shot. The barrier to entry is low and you can choose the level of complexity you want to bring to the table.

RAnDOM Meeting Tomorrow

Brian LeGros | August 27th, 2008 | news  

For anyone who is interested, the first RAnDOM (Rich ApplicatioN Developers Of Melbourne) user group meeting is tomorrow, 08/28, at 7:00 PM @ Goombay’s on A1A. We had to move it back from 08/21 to its new date due to Tropical Storm Faye. We will be covering creating mashups using jQuery and Google Maps and Charts. The code sample is available in the RAnDOM SVN repository. Check out the blog for more information on requirements to participate in coding and please RSVP on EventBrite if you intend to come out. Hope to see you all there!

Moving into the .NET world

Brian LeGros | June 15th, 2008 | programming  

With my latest employer, I have taken the big dive into the .NET world. I’ve spent most of my career working with ColdFusion, Java, PHP, Flex and dabbled a little bit in the Ruby/Rails and Groovy/Grails world in addition to the obvious set of web technologies and standards that span all of these application languages. My limited experience with .NET was through some undergraduate and graduate work I did with C# as well as helping (if you can call it that) with an ASP.NET a long time ago with a colleague of mine. I am a application developer; even though I dabble in lots of different areas, the bulk of my knowledge is building applications in a corporate IT environment. I focus on implementing business requirements and managing technical concerns as it relates to the software development process. I’ve had jobs in the past associated with business and management roles but at the core I am a plain and simple application developer. As I’ve been getting my hands dirty in .NET over the last few months I figured I’d share some of my initial impressions. Please keep in mind, I may be looking at a lot of things in a very naive light, so read what I have as my opinion, ignorant or not.

With context out of the way, I have to say that so far working with .NET hasn’t been a negative experience. There is the whole you’re stuck with Windows thing, but since I’m in fully entrenched in the MS world now, I’ve been able to get past it. There have definitely been some nuances to get used to, but nothing extremely difficult to overcome. Here are a few comments on some of the things I’ve run into thus far:

  • Namespaces in C# aren’t constrained by the file system with respect to partitioning your code. Initially this seemed like a nice decoupling, but I’ve found myself forming more of a dependency on tools to navigate my classes hierarchy rather than just looking into a folder.
  • There is no notion of a shared class path as there is in Java. If you want to get a hold of an assembly to use in your application you’ve got to find it and pull it in. I think there is a configuration option on an assembly that you can use to help, but I haven’t had any experience using it.
  • Assemblies are pretty nice build artifacts. Versioning is addressed out of the box and integrated with the .NET framework. I’m not sure how they stack up against something like OSGI, but I’m enjoying having them around.
  • Everyone says the implementation for generics is better in C# than Java, but as an application developer I don’t notice a difference except that I’ve been told I can use reflection on them in C#. C# also seems to have made a much larger use of them in their core over Java. It seems like stronger typing is a very important practice in the C# world than in my experience with the Java world, but that is probably biased based on how I’ve used Java.
  • There appears to be a very balanced view on uses for metadata (attributes) in .NET. Annotations in the Java world were a great addition to the language, but sometimes their use comes off as abuse; look at a JUnit 4 test suite class for a great example.
  • There are lots of accepted libraries available that are direct ports from the Java community such as NUnit, NAnt, Spring.NET, CruiseControl.NET, NDocs, log4net, etc. Getting comfortable with these libraries was pretty easy since I’d had experience with the Java equivalents.
  • The help systems in .NET leave much to be desired and make me long for Javadocs, Livedocs, RDoc, or anything else. I find myself clicking through a class definitions on MSDN and after two or three links I can finally get to a list of “members” that belong to a class, only to click another link to load another page to see more about the details of that “member”. I have yet to find any easily usable API documentation.
  • .NET has a solid component model available out of the box. WCF is a really simple and tight implementation of a component architecture. Service-orientation is a focus with an emphasis on abstracting away protocols, execution environments, and exposing metadata for a more contractual usage. It has the feel of being an API built around WSDL 2 and many of the WS-* standards, but it goes by many of the concepts, although not by name, identified in Patterns of Enterprise Integration. It’s compatible with synchronous and asynchronous operations and did I mention simple to use? I hope to do some posting about it later.
  • Getting used to assimilating applications into the bowels of the OS seems to be core to the .NET mentality. This is probably just a matter of perspective for the developer, but based on the examples I’ve seen thus far, the user folder, the registry, and Windows\system32 folder are popular hang outs for lots of applications. I’ve been met by quite a looks of confusion when I mention deploying applications without the use of some type of installer. There is a lot of power that you get from this tight coupling with the OS I’ve been told. Unlike my previous shops, writing cross-platform applications doesn’t seem to be a priority for .NET developers, so tight coupling it is.
  • It took me listening to the episode of SER with Anders Hejlsberg to understand better it, but it appears to be that developing in .NET is meant to be an IDE integrated experience via Visual Studio. Regardless of the aspect of development I’ve worked with in .NET thus far, the development experience has been fairly consistent. There is always some visual representation of the code available (where applicable) and a debugger is always around and working no matter the context (desktop, web, etc.). At first it was so simple that I felt like I was missing something, but from what I have read and heard, as much work goes into VS as does the .NET framework, if not more. If anyone has used Netbeans for Java web development, it’s a very similar experience in terms of its integration with the environment.
  • I’ve always seen code insight as a supplemental thing, relying on documentation for the majority of my work, but wow, code insight (intellisense) seems to be the major crutch on which a lot of .NET developers place themselves within VS. What’s weird is that I don’t notice anything different than what you’ll experience when working with Eclipse and Java, in fact, the code insight seems to be limited to code only. I have yet to run into a situation where the IDE makes a suggestion on how something could be written or changed as IntelliJ does for Java. I will admit though, maybe I’m missing something.
  • The visual editors in VS seemed to get abused by .NET developers. I say abuse because quite a few .NET developers I’ve encountered can’t talk to me about their code in any other context but how they dragged-and-dropped controls onto a screen and edited properties. Since I don’t know the in’s and out’s of the tools quite yet, having a conversation is tough. I try to communicate in terms of language agnostic principles and patterns but most of the time all I get are blank stares and judgmental comments about how I am over complicating things.
  • MS alternatives exist in terms of the IDE and runtime, but they don’t seem to be popular at all. I really like SharpDevelop as an alternative to Visual Studio. It’s clean, easy to use, and integrates with a lot of OSS packages out of the box. Mono is available as a Linux-based .NET runtime that has a lot of .NET developers excited because of its potential to allow them to code for the Mac. I don’t know any Mac owners that have Mono installed however, so I don’t know if it’s really a viable cross-platform solution.
  • I have some thoughts on ASP.NET web forms that I want to share, but I’ll save that for my next post.
  • The developer community has always been important to me and I feel it’s always important to remain active in the community in some capacity. As I’ve begun attending the local .NET user group meetings, I don’t see a lot of topics that are not MS centric. There is no question that MS drives the releases of the .NET framework, but there have been lots of innovations coming out of the community that deserve attention. It feels like there are only a small minority of developers that actually utilize these contributions locally. I have yet to see any presentations on the various unit testing tools, build tools, ORM, IoC, etc. that have come out of this space. I do envy the direct support that MS has for its user groups, but I wonder if my expectations are too high.

In any case, so far the learning curve with .NET hasn’t been very steep and when I do get to code I feel fairly productive. I should be posting in the next few days on my thoughts about ASP.NET web forms so I’m sure that will get me flamed, but it’s a major part of the puzzle I’m having to work with that I feel needs some attention. Until next time.