I created this simple utility, called SWFIdle, to enable the Flash Player to lower its CPU usage while the user is not interacting with it. Since it’s possible to have multiple Flash instances embedded in one page (for example, a game and a couple of banners), I recommend that everyone uses this in their projects, so that SWFs needn’t fight for CPU and give Flash a bad name.
09
Jul 11
Dependency Injection by Extension pattern
Since I'm not sure whether I have indeed invented a new design pattern here. So, alternative titles for this post include:
- Dependency Injection without a Dependency Injection framework
- Why misuse of the default namespace for tests is pure evil
- How to make your code more testable without completely messing it up
The problem:
You need to use some kind of Dependency Injection (DI for short) to provision some System Under Test (SUT for short) in tests you're writing, but can't or don't want to use a DI framework to do so.
Of course, the simplest form of DI is simply passing things to a constructor. But you probably don't want to code every class to be handed every dependency at construction. And you definitely don't want to expose the private parts of your implementation through some unnecessary interface. No, you really don't!
I've seen scary examples of what I call 'keyhole surgery' on classes, either by abuse of the internal namespace to allow poking into otherwise private implementation, or just by making too many things public. Although the internal namespace (AKA the default namespace) is perceived to retain a sufficient level of encapsulation, it really doesn't. Anything in the same package can jump all over it, so it's somewhat of a loose interface. As such, you should never leave methods unscoped, letting them default to the internal namespace. You should also reserve the internal namespace only for when you are in control of all classes that will exist in the same package, such as when creating utility classes.
Loose interfaces are bad practice for a few reasons:
- Clarity - anyone using the class will be confused as to the intentions of its interface
- Stability - a class with such a loose interface is open to misuse and a recipe for failure
- Cleanliness - code for tests does not belong in your production code
- Testability - you should test a class through its interface, not its implementation
- Flexibility - it is hard to refactor classes that leak implementation detail in such a way
The solution:
Well, this is one possible solution and ultimately just my suggestion. It's especially useful when needing to refactor classes with overuse of the internal namespace, since you won't need to change much test or production code. I call it the Dependency Injection by Extension pattern.
How it works:
You provide DI helpers as protected methods in your SUT and subclass it from within your test case, as a script-level class, to expose the DI helpers as public and/or use the constructor to do some of the DI work - allowing you to inject mocked dependencies for your tests. This has the advantage of not allowing anything else to meddle with your SUT, other than through its interface, of course. And, if anything in your production code wishes to extend your SUT, potentially overriding and messing up the interface, then that class should have its own tests anyway.
Example:
The following example shows a very basic class (SystemUnderTest) being extended from within its testcase (SomeTest) to allow injection and access to its dependencies, for the purpose of verifying its behaviour under given conditions.
class SystemUnderTest
{
protected var someDependency : Dependency;
private var _someThing : Thing;
{
protected var someDependency : Dependency;
private var _someThing : Thing;
public function SystemUnderTest()
{
someDependency = new Dependency();
_someThing = new Thing();
}
public function doSomething() : void
{
_someThing.callSomething( someDependency.getSomething() );
}
protected function get someThing() : Thing
{
return _someThing;
}
}
package
{
public class SomeTest
{
private var sut : SystemUnderTestWithDI;
private var someThing : Thing;
private var mockDependency : Dependency;
{
public class SomeTest
{
private var sut : SystemUnderTestWithDI;
private var someThing : Thing;
private var mockDependency : Dependency;
public function setUp()
{
mockDependency = mock(Dependency);
sut = new SystemUnderTestWithDI(mockDependency);
someThing = sut._someThing;
}
[Test]
public function testSomething():void
{
var testValue : String = 'foo';
given( mockDependency.getSomething() ).willReturn( testValue );
sut.doSomething();
verify().that( someThing.callSomething( eq(testValue) ) );
}
}
}
class SystemUnderTestWithDI extends SystemUnderTest
{
public function SystemUnderTestWithDI(dependency : Dependency)
{
super();
someDependency = dependency;
}
public function get _someThing() : Thing
{
return someThing;
}
}
16
Jun 11
iPad smoothness for iPad
I'd recently been playing around with packaging AIR for iOS, to run on my iPad. While the performance has been improved massively since CS5 Packager, it's still not great in AIR 2.6. It seems that AIR 2.7 brings with it some great performance enhancements - though I'll reserve judgement until I've tried it myself - check out the article and video here.
07
Jun 11
New version of Playbook ScratchPad live
An updated version of my ScratchPad app for Blackberry Playbook has just gone live. It has a couple more features, including resizable brush and image export.
28
May 11
Mockito gotcha
I recently had a bit of a shock while reviewing someone's code, finding the following line in one of their tests:
verify().that(sut.update());
Where: sut is their System Under Test and verify is the part of the Mockito framework.
Exercise for the reader: What's wrong with this picture?
The answer: You cannot expect Mockito to verify that something was called on anything that isn't a mock! How the hell is it supposed to know?
At least, if attempting to stub a method of a non-mock, you'll get a handy error telling you not to be so damn silly. But, in this case, the verify will always work. So the test will pass, but it isn't actually verifying anything! Where do I start with the bad? This is the worst kind of test, since it provides a false sense of security on the robustness of a system. Thankfully, all the tests in this codebase had called their System Under Test either sut, _sut or SUT, so it was pretty easy to get Hudson to mark a build as unstable if it finds such madness.
11
May 11
A winner is me
So, in my first steps in tablet development, I cracked out a simple app for the new Blackberry Playbook and got a free Playbook! It's a very nice piece of hardware. You can see my app (a very simple doodling application, called ScratchPad) here.
09
Apr 11
Take two tablets and call me in the morning
Well, it's been a while. Having spent the last 8 months working on the YouView set top box platform, I've been so busy that I wasn't even sure my site was still up. And now that I've dived headlong into the tricky world of embedded systems development, I wanted to starting playing with other platforms out there. The first two that recently caught my eye were Apple iOS (specifically the iPad) and the new Blackberry PlayBook.
I was keen to see what the application development process is like for these two platforms, especially for Flash Developers and how the two Big Tablets, iPad and PlayBook, measurement up as potential target platforms for the crazy ideas in my head that I'd want to build. So, I made the first steps at development for both.
iPad
Now that Adobe is 'allowed' to pursue iOS as a target platform for AIR, via its cross-compiler again, I went through the process of signing up as an iOS developer, jumping through the various other hoops and getting my first 'hello world' app onto my iPad. The whole process is a lot more complicated than it probably could be, but then, the same could be said of device development at YouView - this is the nature of such platforms, they are emerging technologies and, as such, are moving targets and simply not like the desktop machines we are all used to developing for. I have to say though, I'm impressed with the recent leaps in performance and functionality Adobe has made with AIR 2.6 for iOS - it leaves Packager in the dust.
PlayBook
Perhaps because the tool chain for PlayBook development feels more like developing for YouView, I was more comfortable with developing for the Playbook and managed to crack out a very simple app, getting in App World in a matter of a couple of days.
Now that I've stepped well outside the desktop comfort zone, I have been playing for a while with resource constrained device development, hardware acceleration of Flash content and developing an unhealthy obsession for writing clean, memory/rendering performance optimal code. I hope to bring some of this to projects for iOS and Playbook, as well as share what I've learned over the last year.
07
Jul 10
How to embed an entire asset SWF and get symbols from it
The problem:
You want to embed an entire SWF, full of assets, into a class and retrieve individual symbols from it - but you don't want to have to embed each asset individually.
The solution:
SWFAsset - a couple of lines of code and you're away.
