You are currently browsing the TDD / BDD archives.

Misplaced Code

Monday, May 31st, 2010

Often I come across what I like to call “Misplaced Code”, that is, code which should be refactored to a specific, independent concern rather than mistakenly being defined in an incorrect context.

For instance, consider the following example to get a better idea of what I mean:

Taking the above example into a broader context, it is quite common to see code such as this scattered throughout a codebase; particularly in the context of view concerns. At best this could become hard to maintain and, at worst, it will result in unexpected bugs down the road. In most cases (as in the above example) the actual code itself is not necessarily bad, however it is the context in which it is placed which is what I would like to highlight as it will almost certainly cause technical debt to some extent.

Considering the above example, should code such as this become redundantly implemented throughout a codebase it is quite easy to see how it can become a maintenance issue as, something as simple as a change to a hostname would require multiple refactorings. A much more appropriate solution would be to encapsulate this logic within a specific class whose purpose is to provide a facility from which this information can be determined. In this manner unnecessary redundancy would be eliminated (as well as risk) and valuable development time would be regained as the code would need only be tested and written once – in one place.

So again, using the above example, this could be refactored to a specific API and client code would leverage the API as in the following:

This may appear quite straightforward, however, I have seen examples (this one in particular) in numerous projects over the years and it is worth pointing out. Always take the context to which code is placed into consideration and you will reap the maintenance benefits in the long run.

Metadata API update for Flex 4

Saturday, January 30th, 2010

Back in September 2008 I published a post on Class Annotations in Flex, through which I provided an API allowing for a unified approach for working with AS3 metadata. Just recently I intended to use the Metadata API in a Flex 4 project when I noticed it no longer seemed to work as expected. After a bit of debugging, I realized the bug appeared to be related to changes in the result returned from describeType; specifically, the addition of the “__go_to_definition_help” metadata. Considering the Metadata API leverages describeType in order to introspect metadata definitions, this made sense.

I made some simple modifications to the API to work with the new metadata returned from describeType and this resolved the issue. While I was in the process I also refactored operations to return Vectors as opposed to ArrayCollections, as was the case in the original design; effectively optimizing the API for Flex 4 (as well as Flex SDK 3.4).

You can download the source/tests/swc/docs dist here; all of which will be available soon via SVN and a public Maven repository, more on that once it’s ready.

Guiding Design with Behavior Verification and Mock Objects

Tuesday, November 24th, 2009

At some point every developer who has disciplined themselves in the ritualistic like art and science of Test Driven Development soon discovers that the collaborators on which a class under test depend introduce an additional layer of complexity to consider when writing your tests – and designing your APIs.

For example, consider a simple test against a class Car which has an instance of class Engine. Car implements a start method which, when invoked, calls the Engine object’s run method. The challenge here lies in testing the dependency Car has on Engine, specifically, how one verifies that an invocation of Car.start results in the Engine object’s run method being called.

There are two ways of testing the above example of Car, which in unit testing nomenclature is called the System Under Test (SUT), and it’s Engine instance which is Car's Depended-on Component (DOC). The most common approach is to define assertions based on the state of both the SUT and it’s DOC after being exercised. This style of testing is commonly referred to as State Verification, and is typically the approach most developers initially use when writing tests.

Using the above Car example, a typical State Verification test would be implemented as follows:

Figure 1. CarTest, State Verification.

From a requirements perspective and therefore a testing and implementation perspective as well, the expectation of calling start on Car is that it will A.) change it’s running state to true, and B.) invoke run on it’s Engine instance. As you can see in Figure 1, in order to test the start method on Car the Engine object must also be tested. In the example, using the State Verification style of testing, Car exposes the Engine instance in order to allow the state of Engine to be verified. This has lead to a less than ideal design as it breaks encapsulation and violates Principle of Least Knowledge. Obviously, a better design of Car.isStarted could be implemented such that it determines if it’s Engine instance is also in a running state; however, realistically, will likely need to do more than just set its running state to true; conceivable, it could need to do much, much more. More importantly, while testing Car one should only be concerned with the state and behavior of Car – and not that of its dependencies. As such, it soon becomes apparent that what really needs to be tested with regards to Engine in Car.start is that is invoked, and nothing more.

With this in mind, the implementation details of are decidedly of less concern when testing Car; in fact, a “real” concrete implementation of Engine need not even exist in order to test Car; only the contract between Car and Engine should be of concern. Therefore, State Verification alone is not sufficient for testing Car.start as, at best, this approach unnecessarily requires a real Engine implementation or, at worst, as illustrated in Figure 1, can negatively guide design as it would require exposing the DOC in order to verify its state; effectively breaking encapsulation and unnecessarily complicating implementation. To reiterate an important point: State Verification requires an implementation of Engine and, assuming Test First is being followed (ideally, it is), the concern when testing Car should be focused exclusively on Car and it’s interactions with its DOC; not on their specific implementations. And this is where the second style of testing – Behavior Verification – plays an important role in TDD.

The Behavior Verification style of testing relies on the use of Mock Objects in order to test the expectations of an SUT; that is, that the expected methods are called on it’s DOC with the expected parameters. Behavior Verification is most useful where State Verification alone would otherwise negatively influence design by requiring the implementation of needless state if only for the purpose of providing a more convenient means of testing. For example, many times an object may not need to be stateful or the behavior of an object may not always require a change in it’s state after exercising the SUT. In such cases, Behavior Verification with Mock Objects will lead to a simpler, more cohesive design as it requires careful design considerations of the SUT and it’s interactions with its DOC. A rather natural side-effect of this is promoting the use of interfaces over implementations as well as maintaining encapsulation.

For testing with Behavior Verification in Flex, there are numerous Mock Object frameworks available, all of which are quite good in their own right and more or less provide different implementations of the same fundamental concepts. To name just a few, in no particular order, there are asMock, mockito-flex, mockolate and mock4as.

While any of the above Mock Testing Frameworks will do, for the sake of simplicity I will demonstrate re-writing the Cartest using Behavior Verification based on mock4as – if for nothing other than the fact that it requires implementing the actual Mock, which helps illustrate how everything comes together. Moreover, the goal of this essay is to help developers understand the design concepts surrounding TDD with Behavior Verification and Mock Objects by focusing on the basic design concepts; not the implementation specifics of any individual Mock Framework.

Figure 2. CarTest, Behavior Verification approach.

Let’s go through what has changed in CarTest now that it leverages Behavior Verification. First, Car's constructor has been refactored to require an Engine object, which now implements an IEngine interface, which is defined as follows.

Figure 3. IEngine interface.

Note Engine.isRunning is no longer tested, or even defined as, it is simply not needed when testing Car: only the call to is to be verified in the context of calling Car.start. Since focus is exclusively on the SUT, only the interactions between Car and Engine are of importance and should be defined. The goal is to focus on the testing of the SUT and not be distracted with design or implementation details of it’s DOC outside of that which is needed by the SUT.

MockEngine provides the actual implementation of IEngine, and, as you may have guessed, is the actual Mock object implementation of IEngine. MockEngine simply serves to provide a means of verifing that when Car.start is exercised it successfully invokes; effectively satisfiying the contract between Car and Engine. MockEngine is implemented as follows:

Figure 4. MockEngine implementation.

MockEngine extends org.mock4as.Mock from which it inherits all of the functionality needed to “Mock” an object, in this case, an IEngine implementation. You’ll notice that does not implement any “real” functionality, but rather it simply invokes the inherited record method, passing in the method name to record for verification when called. This is the mechanism which allows a MockEngine instance to be verified once run is invoked.

CarTest has been refactored to now provide two distinct tests against Car.start. The first, testStartChangesState(), provides the State Verification test of Car; which tests the expected state of Car after being exercised. The second test, testStartInvokesEngineRun(), provides the actual Behavior Verification test which defines the expectations of the SUT and verification of those expectations on the DOC; that is, Behavior Verification tests are implemented such that they first define expectations, then exercise the SUT, and finally, verify that the expectations have been met. In effect, this verifies that the contract between an SUT and its DOC has been satisfied.

Breaking down the testStartInvokesEngineRun() test, it is quite easy to follow the steps used when writing a Behavior Verification test.

And that’s basically it. While much more can be accomplished with the many Mock Testing frameworks available for Flex, and plenty of information is available on the specifics of the subject, this essay quite necessarily aims to focus on the design benefits of testing with Behavior Verification; that is, the design considerations one must make while doing so.

With Behavior Verification and Mock Objects, design can be guided into existence based on necessity rather than pushed into existence based on implementation.

The example can be downloaded here.

Thoughts on Cairngorm 3

Sunday, October 18th, 2009

A week or so prior to MAX, the Cairngorm committee had a rather interesting discussion, during which Alex outlined what the team at Adobe Technical Services had been considering for Cairngorm 3. The meeting was focused on providing everyone with an overview of the collective ideas which Adobe had been gathering internally for some time now, and to also inquire feedback prior to the public announcement of Cairngorm 3.

Prior to the meeting I had anticipated the discussion would be based around a few new patterns and best practices which are currently being advocated, and possibly some additional libraries which help to address recent challenges in RIA development. However, what we discussed was actually quite different – in a good way.

As you are probably aware by now, Cairngorm 3 is focused around tried and tested best practices and guidelines which aid Flex developers in providing solutions to their day to day RIA challenges. These guidelines are primarily based upon that which has been realized by Adobe Technical Services, and also from the Flex community at large. Teams can leverage these guidelines where applicable to help deliver successful RIAs using frameworks of their choosing. While there may be specific frameworks and libraries recommended in Cairngorm 3, these are just that – recommendations. There is generally a framework agnostic approach which I must emphasize is highly preferable to that of suggesting one framework over another. This is precisely what I think is needed in the Flex community, for there is rarely a one size fits all approach to software architecture, especially in terms of specific framework implementations. This is a pretty easy concept to comprehend, as, what works for one team, in one context, may not always be appropriate for another team, or in another context.

Cairngorm 3 is a step forward towards what (IMHO) should be a general consensus in the Flex community at large; there are many existing frameworks out there which help address specific problems, with each providing unique qualities and solutions in their own right. This is the kind of thought leadership which helps a community progress and grow; it should be encouraged, as allowing for the shared knowledge of fundamental design principles and guidelines is something which provides value to all Flex developers, regardless of which framework they happen to prefer.

If there is one suggestion I would propose, it would be to have an entirely new name for these collections of best practices, guidelines and general Flex specific solutions. Personally, I would like to see the name Cairngorm (which, after all these years, I still pronounce as Care-in-gorm) refer to the original MVC framework, i.e. the framework implementation itself, as keeping the name the same while undergoing a different direction is bound to cause confusion to some extent. Whatever the new name would be is insignificant as long as the original name of Cairngorm applied to that of the actual framework implementation. This would perhaps be more intuitive as it would allow for the name Cairngorm to be used to describe a concrete framework as a potential solution, just as one could describe other frameworks; e.g. Spring ActionScript, Mate, Swiz, Parsley, Penne, Model-Glue, PureMVC, Flicc etc.

Most importantly, however, is the prospect of choice, as choice is always a good thing. Moreover, an initiative being lead by Adobe in this area sends a very good message to the Flex community as a whole. I happen to leverage a number of different frameworks and patterns which address different problems. As new problems arise, I employ new solutions where existing solutions may not suffice, or develop custom solutions where none are currently available; never blindly choosing one solution over another. However, in every case, there are typically some basic, fundamental guidelines which hold true and can be followed to help drive a design in the right direction. Regular readers of this blog have probably noticed that the basis of the majority of my posts are heavily rooted within these fundamental design principles, as it is from these fundamental design principles and guidelines that developers can utilize the frameworks which work best for them in order to and meet their specific challenges.

Essentially, Software Architecture is all about managing complexity, and there are many fundamental patterns and guidelines which can help developers mange this complexity. The specific framework implementations are of less concern, for it is the understanding of these patterns and principles – and more importantly, when to apply them, which will ultimately drive the decisions to leverage a one framework over another. In my experience, I have found that the only constant in software architecture is that a pragmatic approach should be taken whenever possible, whereby context is always key, and simplicity is favored as much as possible. Cairngorm 3, I feel, is a nice illustration of this principle.

Open Source AS3 APIs

Sunday, August 30th, 2009

For the past 4 years or so I have provided quite a few AS3 APIs as Open Source to the Flex Community, via my blog. These APIs can typically be found at the Open Source AS3 APIs page however, the page is basically just a URI to a series of arbitrarily added AS3 source classes. It was originally intended to simply serve as a convenient location to access the source, and it had always been my intention to eventually break out all of these APIs into seperate SVN projects.

So with that being said I am finally in the process of making the structural changes I had originally envisioned. Moving forward I will begin the process of creating seperate SVN projects for these Open Source APIs; with the primary goal being to provide practical APIs that only require minimal (if any) dependencies on additional libraries, complete test coverage via Flex Unit 4 and Mavenized builds.

The first project to move over to the new project structure will be the AS3 collections project as the classes in this package, specifically HashMap, have proven to provide the most value according to community feedback.

So stayed tuned!

Flex Mojos 3.2.0 Released

Monday, May 18th, 2009

Sonatype recently released the latest version of Flex Mojos, which is now at version 3.2.0.

This latest update is a big step forward for Flex / AIR Developers managing their project builds and dependencies with Maven 2 as the updates are focused around unit testing support improvements; including support for headless mode on Linux based CI servers and, more importantly, a fix for running automated unit tests in multi-module builds; which was a big head scratcher for me about a month ago!

Below is a list of what I feel are the most significant updates in 3.2.0:

  • Added support for SWF optimization
  • Multi-module builds now run tests correctly across projects
  • Changes to the way flex-mojos launches flash player when running test harness
  • Long-running flexunit tests no longer cause the build to fail.
  • Fix to NullPointerException during flex-mojos:test-run goal
  • You can view the complete list of release notes here.