Brian Kotek: Inversion of Control - ColdMock

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. ;-)

BeanInjector Update (now at RIAForge!) and ColdMock update

Wed, 12 Mar 2008 15:02:00 -0700

I've updated the BeanInjector component and have created an RIAForge project to host these until we can figure out where these will live in the ColdSpring repository. The ColdSpring Bean Utilities project is at http://coldspringutils.riaforge.org/. It includes the BeanInjector and TDOBeanInjectorObserver, as well as the AbstractMetadataAwareAdvice, VOConverterAdvice, and GenericVOConverter. A zip file and Subversion access are available at RIAForge. There is an update to the BeanInjector specifically. Bob Silverberg noticed a non-var-scoped variable during the initial caching of the metadata for the target object. This shouldn't actually affect anyone since the code lives in an exclusive lock, but better safe than sorry. Thanks Bob! There's also a small update to ColdMock. You can now pass an optional argument named "isVirtualMethod" when you define a mock method. By default this is false, but if you specify true, ColdMock will skip all checks for the existence of the method, as well as argument and return type checks. This is useful if you want to mock a method that is injected dynamically into the component, since the metadata for the object will have no information on the dynamic method. So basically, you can define what the method will return, but you're on your own as far as making sure it is accepting and returning the proper types. I hope folks find these useful!

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).

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?