Unit Testing: IoC/DI, Robotlegs and FlexUnit 4
I've been reviewing the various IoC containers available for Flex/Actionscript. One of the benefits of IoC and DI is that it greatly facilitates unit testing. By injecting our dependencies into our applications actors, we are effectively isolating them from the other classes that make the application function. "So what?"
In computer programming, unit testing is a software verification and validation method in which a programmer tests that individual units of source code are fit for use. A unit is the smallest testable part of an application. In procedural programming a unit may be an individual program, function, procedure, etc., while in object-oriented programming, the smallest unit is a class, which may belong to a base/super class, abstract class or derived/child class.
Ideally, each test case is independent from the others: substitutes like method stubs, mock objects, fakes and test harnesses can be used to assist testing a module in isolation. Unit tests are typically written and run by software developers to ensure that code meets its design and behaves as intended. Its implementation can vary from being very manual (pencil and paper) to being formalized as part of build automation. -wikipedia unit testing entry
To effectively unit test classes, we want them to be as isolated as possible. The class needs to stand on its own and have its functionality vetted to ensure that it behaves as expected. When we start to test how our classes behave together, we have entered the land of integration testing. Integration testing is a worthwhile pursuit also, but before we get to that point, we really want to ensure that our classes are solid by themselves.
Using the example in this Robotlegs Image Gallery demonstration, we are going to test a couple of the classes that make up the application. The demo isn't complex. It has a very simple model, a single service, and just a few views. In fact, it might even seem like a waste of time to unit test a simple example such as this, but the concepts are applicable to larger applications where the benefits of this type of testing really start to pay off.
FlexUnit 4 is the framework that is used here. It provides very handy asynchronous testing, meta data support, and a whole bucket of stellar features that I won't even begin to scratch the surface of. FlexUnit 4 also comes with a graphical testrunner interface:
Bram Cohen on what it takes to be a great programmer.
There are only two coding skills which mostly people who are completely self-taught as a programmer miss out on: proper encapsulation, and unit tests. For proper encapsulation, you should organize your code so that changes which require modifying code in more than one module are as rare as possible, and for unit tests you should write them to be pass/fail so that all unit tests can be run as a comprehensive suite. And now you know everything you need to about those two things. Anyone who is taught the above guidelines, and decides they really want to learn those skills, will with sufficient practice become good at them.
Coding skill is all well and good, and you can't become a great programmer without it, but it's far from everything. I'm decent at raw coding, but I know many people who are better, and some of them are abysmal programmers. I in particular can't deal with being tasked with fixing up spaghetti code. My brain simply locks down and refuses to make any modifications which it isn't convinced will work, which is of course impossible when the source material is an incurably bug-ridden mess.
I've felt this way about my own code with almost everything I've written to date. It has been a struggle for me, to go from an unstructured mess to something other people might be able to look at without throwing up.
It is apparent why people might skip over the 'proper encapsulation and unit tests' while teaching themselves software programming in a non-formal way. They are easily overlooked, and without a grade-book shaped stick hovering over your backside to force that sort of formality, one could easily just slide past these skills and program off the cuff. One of my challenges in learning to program has been to build things properly, to not re-invent the wheel every single time I sit down to make something meaningful in software. My preference is to stand on the shoulders of those that have come before me, and use the collective knowledge of masters, past and present, to expand my understanding and knowledge in appropriate directions. The trick is to do all of this with an open mind. We need to evaluate new ideas and differing opinions without locking onto one particular nerd dogma. I don't know that I will ever be a great programmer, but I will have fun trying.
Here's another interesting piece regarding software education and what it takes to be a great programmer: Who Killed the Software Engineer? (Hint: It Happened in College)
FlexUnit – Some useful examples and tutorials covering unit testing in Flex and Actionscript 3.0
In an effort to build my skills and create applications that are based on a firm foundation, I am implementing unit testing. So far I am completely sold on the concept, and while I'm not quite to the point of full TDD, I can see the benefits immediately with the tighter code and confidence level that accompanies it. Here are some of the useful resources that I came across in my research. They are all centered around FlexUnit, the 'official' unit testing framework for Actionscript 3.
Neil Webb has an article on Adobe's Developer Center that covers the basics of getting started with FlexUnit. It is thorough and easy to read. This is probably the best starting off point that I have come across
Theo Hultberg has some valid critiques of the framework, as well as an alternative approach to the 'Temperature Conversion' example that is supplied with the FlexUnit distribution. I found this to be extremely helpful in deciphering FlexUnit and getting it up and running in my project.
Eric Feminella has created a simple API called TestUnitHelper that includes static methods to eliminate some of the tedium involved with creating unit tests with FlexUnit. There is some overlap with some of the points Theo touches on in terms of parsing test methods, but Eric's API is straight forward and gets the job done. Eric is a busy man, be sure to check out the trove of other useful APIs while you are there.
Daniel Rinehart gives a decent explanation of how to handle asynchronous calls in FlexUnit tests in the Flex Cookbook (beta). He also writes up another similar example over on his blog. I'm still not quite there with this concept, but these articles are a step in the right direction.
1/23/08 - I found this page with a huge repository of FlexUnit resources.
