Brian Kotek: Inversion of Control - Unit Testing

Using the Swiz AutowiredTestCase

Tue, 15 Jun 2010 09:27:00 -0700

One of the utility classes that is part of the Swiz library is AutowiredTestCase. As the name implies, you can use this class to help test your Swiz applications. In this case, code will show what's going on much better than doing a lot of typing, so here is a sample FlexUnit 4 test case. First, the class under test:

js|
package com.briankotek.flex4swiztests.control
{
	import com.briankotek.flex4swiztests.event.MyEvent;
	import flash.events.IEventDispatcher;

	public class MyController
	{
		
		[Dispatcher]
		public var dispatcher : IEventDispatcher;
		
		public var didSomething : Boolean = false;
		
		[Mediate( event="MyEvent.CONTROLLER_ACTION_REQUESTED" )]
		public function handleAction() : void
		{
			didSomething = true;
			actionComplete();
		}
		
		private function actionComplete() : void
		{
			dispatcher.dispatchEvent( new MyEvent( MyEvent.CONTROLLER_ACTION_COMPLETE ) );
		}
		
	}
}

You can see this is a simple controller, which responds to the CONTROLLER_ACTION_REQUESTED event, updates a property, and then dispatches CONTROLLER_ACTION_COMPLETE. We want to test that the controller is responding to the correct event, property updating the property, and finally dispatching the completion event. The event itself is a simple event class:

js|
package com.briankotek.flex4swiztests.event
{
	import flash.events.Event;
	
	public class MyEvent extends Event
	{
		public static const CONTROLLER_ACTION_REQUESTED : String = "controllerActionRequested";
		public static const CONTROLLER_ACTION_COMPLETE : String = "controllerActionComplete";
		
		public function MyEvent(type:String)
		{
			super(type, true, false);
		}
	}
}

Finally, the test case itself:

js|
package com.briankotek.flex4swiztests.control
{
	import com.briankotek.flex4swiztests.control.MyController;
	import com.briankotek.flex4swiztests.event.MyEvent;
	import org.flexunit.Assert;
	import org.flexunit.async.Async;
	import org.swizframework.core.*;
	import org.swizframework.utils.test.AutowiredTestCase;

	public class MyControllerTestCase extends AutowiredTestCase
	{	
		private var myController : MyController;
		
		[Before]
		public function setUp():void
		{
			myController = new MyController();
			
			swizConfig = new SwizConfig();
			swizConfig.eventPackages = "com.briankotek.flex4swiztests.event.*";
			
			beanProviders = [new BeanProvider( [myController] )];
		}
		
		[After]
		public function tearDown():void
		{
			myController = null;
		}
		
		[Test(async)]
		public function testControllerActionRequested() : void
		{
			Assert.assertTrue( "Controller property is already true.", myController.didSomething == false );	
			Async.handleEvent( this, swiz.dispatcher, MyEvent.CONTROLLER_ACTION_COMPLETE, checkEvent ); 
			swiz.dispatcher.dispatchEvent( new MyEvent( MyEvent.CONTROLLER_ACTION_REQUESTED ) );
		}
		
		private function checkEvent( event : Event, passThroughData : Object ) : void
		{
			Assert.assertTrue( "Controller property was not updated.", myController.didSomething == true );	
		}
		
	}
}

I start off setting up an instance of Swiz that my test can use. AutowiredTestCase has a method marked with [Before] metadata, so that FlexUnit runs it before each test. I create an instance of the class under test (MyController), then set the event packages on the SwizConfig. Finally, I place the MyController instance into a BeanProvider, so that Swiz will process it as a bean. This way, any Swiz metadata in MyController is processed. The test method dispatches a CONTROLLER_ACTION_REQUESTED event. If all goes well, the mediated event in the controller should run, update the property, and then the controller will dispatch the completion event. Running the test produces a passing result, so everything is working as expected! Note that because Swiz actually processes your test case itself as a bean, you can use Swiz metadata in your test if you want or need to. So injecting a dispatcher, mediating an event, or testing custom metadata processors are all possible as well.

My IECFUG Presentation Recording and Files

Tue, 15 Jul 2008 13:44:00 -0700

Last Friday I gave a presentation to the Inland Empire ColdFusion User Group. It covered a range of topics: MXUnit, ColdMock, and elements of my RIAForge FormUtilities and ColdSpring Bean Utilities projects. The presentation went well, I think. There are a few technical issues towards the end when they were trying to set up a microphone to get a Q&A going, but they are minor. I've linked to the files and the recording below in case anyone is interested in having a look. Thanks again to Sami, Luis, and the IECFUG for allowing me to present!

Small Update to ColdMock

Fri, 21 Mar 2008 10:15:00 -0700

In response to a thread on the MXUnit forums about mocking, I've made a quick update to ColdMock. I added a method named methodCallCount(methodName) to the mock objects. This will return the number of times that the specified method has been called up to the current execution point. This might be useful if you are testing a component that makes calls to a mock object but doesn't return anything or returns void, to ensure that the call to the mock object actually happened as expected. So you can do something like:


Call a method that retuns void: 
This call to facade.methodCallCount('doSomething') should be 1: #facade.methodCallCount('doSomething')#

I also added a debug method called coldMock_debug() to the mocked objects to view the internal variables scope aid in any debugging issues with mocking. Happy mocking! nyah nyah! Oh, not that kind of mocking. ;-)

Unit Testing Transfer Decorators with CFCUnit, BeanInjector, and ColdMock

Mon, 28 Jan 2008 12:18:00 -0700

Paul Marcotte asked me to post about how one might unit test a Transfer Decorator. So here you go Paul (and anyone else who might be interested) :-) . To start with, basic testing of a Transfer Decorator is really no different than testing any other component. First, I set up a ColdSpring file to use for the test. Note that, depending on how many things you need to test and what you're testing, you can use the same ColdSpring file to test numerous things. In other words, you don't necessarily have to have a separate ColdSpring XML file for every test.



	
	
	   /tests/transfer/testing/datasource.xml
	   /tests/transfer/testing/transfer.xml
	   /tests/transfer/testing/definitions

From here, the unit test might look like this (I'm using CFCUnit but the approach in CFUnit would be similar):

As you can see, you grab the Decorator from Transfer, and then are free to test the methods in the Decorator the same way you would test any other CFC method. To take this further, you can actually mix a number of the techniques that I've talked about to handle more complex tests. In this example, I'm using the TDOBeanInjectorObserver to wire in a ValidatorFactory to my Decorator. However, to keep the test isolated to the Decorator, I'm using ColdMock to create a mock of the ValidatorFactory and injecting that into the Decorator:



	
	
	   /tests/transfer/testing/datasource.xml
	   /tests/transfer/testing/transfer.xml
	   /tests/transfer/testing/definitions
	
	
	

	
	
	
		
			tests.transfer.testing.ValidatorFactory
		
	
	
	
	
		false

This way, I can test any methods in the Decorator that actually rely on the ValidatorFactory by mocking the results from the ValidatorFactory method calls:

Just for reference, the Decorator I'm using in these test examples looks like this:

Hopefully that helps clear up how one might go about testing a Transfer Decorator. It also shows how you can use unit testing, ColdMock, and the Transfer Bean Injector together. Please let me know what you think or if you have any questions or comments about how I'm doing this.

ColdMock and CFC Stub Generator Updates

Wed, 14 Nov 2007 12:01:00 -0700

Just a quick note about some updates to the RIAForge projects for ColdMock and the CFC Stub Generator. ColdMock had an issue when trying to mock a method that was defined in a superclass of the target object. This has been corrected. It will also validate arrays of components as return types (i.e. User[]) (thanks to João Fernandes for contributing this fix). The CFC Stub Generator has some significant additions as well. The tool now supports generating private and public properties if you define these in the UML. Public properties are set in the THIS scope, and associated cfproperty tags are created. The tool also supports existing CFCs now. It will not overwrite existing components, but will still generate the other files (unit tests, ColdSpring, etc.). This will allow you to quickly generate unit tests for an existing set of components by spec'ing them out in UML. You can also set up alternate package hierarchies in the tool to define paths to CFCs that are outside of your project (for example, Transfer), and mark a CFC as "active" in the UML tool to instruct the generator to use this path as opposed to the root path you defined for your main project. You must set up the alternate package path and set the base package for the alternate packages as "root" in the UML tool. In this way, the generator will know the proper paths to the external components for typing and ColdSpring path creation. Examples of this setup are included in the bookstore2.zuml/bookstore2.xmi files. Finally, the tool now has an option to use ColdMock instead of generating staic mock CFC files, and configure the unit tests and the generated ColdSpring file to use the MockFactory to use in the unit tests (requires ColdMock and CF8).

Get Model-Glue Training, With ColdSpring, Transfer and Reactor Too

Wed, 07 Nov 2007 10:49:00 -0700

Just a quick note that Doug recently posted about a sweet price decrease for his first Model-Glue training class. Setting up a training business is difficult so the price drop doesn't surprise me at all. You really need to build up a base of happy students who spread the word, and in the beginning that means you need appealing pricing. Well, this is good news for anyone interested in building their ColdFusion skill set. Not only will you get a good dose of Model-Glue, from the basics on up, but there are course sections on CFCUnit, ColdSpring, Transfer, and Reactor as well. Given the number of questions on various lists and blogs about MVC, dependency injection, object-relational mapping, and general object-oriented programming concepts, this seems like a great way to get your head around a lot of topics quickly and efficiently. Just because some of us long-time CF'ers had to beat our heads against he wall trying to learn things doesn't mean you have to! (I could also tell you about walking to school in the snow uphill both ways...) Anyway, the upshot is that anyone in the midst of trying to learn these things should definitely have a look at the class. $800 is just really darn cheap, and I wouldn't expect it to stay at that kind of price point for very long. Get in while the getting is good.

ColdMock Now Available at RIAForge

Thu, 30 Aug 2007 11:10:00 -0700

OK I've finished up my initial work on ColdMock and have released it as a project on RIAForge. The zip file and SVN repository contain the ColdMock factory as well as some examples of how it can be used. I added what I think is a crucial element: validation of arguments and return values for the mocked methods. This was actually pretty challenging to add. This is because once the MockFactory creates an instance of your component, it purges all of the existing methods from that instance. It must do this so that your original methods don't run, since that defeats the whole point of using a Mock object. You don't want the original methods to run, since they will have code in them or references to other objects in them. Mocks just return the dummy data you specify. However, purging all the existing methods also means all the arguments, argument types, and return types are also gone. To work around this, the Mock object uses the original component's metadata. When you call a method, onMissingMethod() runs. It then loops through the metadata and checks that all required incoming arguments are present, that the types are correct (if you specified a type in the original argument), and that the return value that you have specified is of the correct type as well (if you specified an original return type). The possible combinations of untyped arguments, optional arguments, named vs. positional arguments, native types vs. CFC types, etc. made this quite difficult to implement. Basically, I had to write code that mimics all of CF's built in required argument and type checking! However, I believe I have it working for all of those situations. If anyone runs into a situation that isn't handled properly, please submit an issue at the RIAForge project.

Unit Testing with ColdMock To Dynamically Generate Mock Objects

Tue, 28 Aug 2007 12:45:00 -0700

I was at the RailsEdge conference in Chicago last week to hear some people talk about Ruby on Rails. I may post a separate entry about my thoughts on that conference and Rails, but this post goes in a different direction. One of the interesting things I saw was leveraging the dynamic nature of Ruby to create mock objects on the fly for use in your tests. It was a pretty cool idea since writing and managing "real" mock objects is kind of a pain. So I sat down and created a mock generator in ColdFusion in about an hour. I think I will call it ColdMock (not very original, I know, but I'm not a marketing guy). If you are not familiar with Mock objects, here is the idea. When you test a CFC, you want to test ONLY that CFC. However, in a real application, CFCs often depend on other CFCs to work. It is very difficult to test these CFCs, because you're really testing the entire tree of dependent CFCs at once. To avoid this, you would substitute Mock objects for the dependent CFCs. As far as the CFC you are testing is concerned, the Mock objects act exactly the same as the real components. However, they have no actual code in them. They just return dummy data to the CFC you are testing. This way, you are only testing a single CFC, which is the entire point of a good unit test. Up until now I have been writing (or, more often, using my CFC Stub Generator to generate) actual Mock CFC files. The problem is that you still have to go into the file and hard code return values for them. And if you need to call the method more than once during a test, you have to figure out some way to make the method return different values for the different calls. And the return values are then immutable, unless you go back in and re-edit the Mock CFC. It works, and it's definitely better than nothing, but ColdMock will make handling this much easier. It works like this: you tell ColdMock which CFC you want to mock. It will create an instance of the original component, then purge all of its methods and dynamically attach a new set of methods that handle the mocking duties. This means that you no longer need to actually create a separate Mock CFC file. Once ColdMock gives you back your mock CFC, you declare what methods you want to mock and what values the mock method will return. Then you can test your CFC, and when it needs to call the CFCs it depends on, your Mock components will return whatever values you specified. Since just reading the description of what it does might not make things clear, let's look at some code. I'll start with a very simple example. I want to mock out a SessionFacade component.









#facade.doSomething()#

This creates the mock facade object, then says "when I call a method, any method, on the facade, return 32". You can also define multiple return values like this:



#facade.doSomething()# #facade.doSomething()# #facade.doSomething()#

Which will return a different value each time, based on the order you defined them. This works for fairly straightforward situations, but you might also need to define different values (or sets of values) for specific method calls. You can do this as well:




#facade.getLastUserLogin()# #facade.getLoginCount()#

The return values can be anything. You can specify a string, a structure, or even a CFC instance, such as:

This should get across how the mocks work. The real benefit comes when you use them in your unit tests. You can create the mocks yourself, or if you use something like ColdSpring, you can have ColdSpring resolve the dependencies by creating mocks and injecting them into the CFC being tested. Let's say I have a Trip CFC that I want to test. The Trip CFC depends on a SessionFacade CFC to do its work. I can create a ColdSpring XML file that my unit tests can all use which will handle the dependencies. It seems like a lot of work but it really isn't, and you probably can use one ColdSpring file to handle dependency resolution for all of your unit test files. Here is my simple ColdSpring XML:


   
   
	
		
			
		
	
   
	
		
			tests.coldmock.SessionFacade

Now, my CFCUnit test might look like this:

So now I can test my Trip CFC in total isolation. Even though it depends on the SessionFacade in my real application, I can substitute it with a mock to run my tests. I can easily define what the method calls to the mock objects will return right in my test. So I don't need to create or edit any Mock CFC files. This makes using mocks and writing good tests much easier. Unfortunately, because it uses onMissingMethod(), it will only run on ColdFusion 8. This might not be a huge issue because most people will probably be running the developer edition of ColdFusion 8 locally. However, I'll keep trying to see if I can get it to work in a way that doesn't require onMissingMethod. I'm still working on this but I should have something ready for release shortly. I'll be putting it up at RIAForge. In the meantime, I'm very interested to hear what people think. Any ideas, comments, or criticism of the idea?