We have added a new FeedBack Forum to all of the ColdBox websites so it makes it easy for the community to report new features, ideas, enhancements and bugs.  Not only that, but we can all vote for what features to support or build and so much more.  So please check it out, by going here:  http://coldbox.uservoice.com/ or just by clicking on the new feedback tabs on the sites.

This is a reminder that will be having a 1 day training at CFUnited 2009 on August 11th.  This is a full day of ColdBox training and goodness.  You don't want to miss this!  The course we will be delivering is CBOX-100 and you can find more information about it here.

Intro to ColdBox is an intense 1-day training course that will get you started with ColdBox Application Development. This course focuses on the main aspects of ColdBox Development and it delivers a one-two punch to get you started.

So if you are ready to jumpstart your ColdBox Development, then register now for this 1 day course that will get you up to speed with ColdBox.

One of the nice things about ColdBox's model integration features are the ability to inject objects by using annotations via the cfproperty tag.  This gives a cleaner API to objects that don't really need to expose setters just for dependency injection purposes.  Why? well, in MY opinion, objects should be shy and only expose what they need to expose to the outside world.  By leveraging annotations, I can cleanly define the dependencies of my object and what is even better, it can even be self-documenting because they are cfproperties.  Not only that, since ColdFusion is a dynamic language and NOT JAVA, we can leverage much more than traditional setter/constructor dependency injection. In our next release, 3.0.0, we will expose our model integration features as a new dependency injection (IoC) framework which we are tentatively naming BlenderBox.  More about BlenderBox in other posts. So now that we introduced that ColdBox can blend your object's with other objects via annotations, how do we test them?  We have no setters or constructor arguments to inject them.  Well, but we do have mxunit and MockBox, which make our lives simpler and HAPPY!! So let's look at a simple service I am currently developing: <cfcomponent name="BetaTransferService" output="false" extends="beta2007.beta94.model.baseobjects.BaseService" hint="The main beta transferring service">

<!--- Dependencies -->
<cfproperty name="betadao" type="model" scope="instance">
<cfproperty name="configBean" type="model" scope="instance">

ALL OTHER METHODS HERE

<!--- onDIComplete -->
<cffunction name="onDIComplete" access="public" returntype="void" output="false" hint="Called after wiring is done">
<cfscript>
/* Setup Configurations */
var config = instance.configBean;

setProgramID(config.getKey('programID'));
setDefaultPublicRole(config.getKey('DefaultPublicRole'));

/* Get the program record */
instance.programRecord = instance.betadao.getProgramRecord(getProgramID());
</cfscript>
</cffunction> As you can see, I have a method called onDIComplete() which is called by BlenderBox after all dependency injection is finalized. Basically, my component has been created, injected and now it will be configured. I get some settings from my configuration bean, call my dao for a program record and finalize. Simple stuff, so let's test this puppy. First of all, I will create my setup method with my target cfc and dependencies. function setup(){
/* Create Mocks */
mockDAO = getMockBox().createMock(className="beta2007.beta94.model.betaweb.BetaDAO",clearMethods=true,callLogging=true);
mockConfig = getMockBox().createMock(className="coldbox.system.beans.configBean",clearMethods=true);
/* Mock Individual Settings */
mockConfig.$("getKey").$args("programID").$results("pid123");
mockConfig.$("getKey").$args("DefaultPublicRole").$results("BetaUser");

/* Create Target Service,decorate it with Mocking Capabilities, and init it
All in one single line via MockBox
*/
beta = getMockBox().createMock(className="beta2007.beta94.model.betaweb.BetaTransferService",callLogging=true).init();
/* Inject Mocks */
beta.$property("betaDao","instance",mockDao);
beta.$property("configBean","instance",mockConfig);
} What I do first is create my mock dao and mock config object. I then proceed to mock the 'getKey' method in my config object with several key target arguments and what they should return. Then I create my target object to test wich I also want decorated with mocking capabilities (just in case I need method spies) and init it. I then proceed to inject it with the mock objects into their appropriate variables in the correct scope /* Inject Mocks */
beta.$property("betaDao","instance",mockDao);
beta.$property("configBean","instance",mockConfig); So by leveraging MockBox's $property() method, I can inject properties into my target object. This is how I inject my dependencies. So let's proceed now to see my onDiComplete test. function testonDiComplete(){
/* Fake Program Record via ColdBox querySim() */
pRecord = querySim("program_id,name,release_phase_id,active,published
       #createUUID()#|Beta Program|#createUUID()#|1|1");
/* Mock Dao Call */
mockDAO.$("getProgramRecord",pRecord);   
/* Run onDI Complete */
beta.onDIComplete();
/* My Asserts */
assertEquals(precord, beta.getProgramRecord(),"program record");
assertEquals(beta.getProgramID(),'pid123');
assertEquals(beta.getDefaultPublicRole(),'BetaUser');
} So in my DI complete test, I first mock a query by using the ColdBox's querysim() method, I then mock the call to my dao's getProgramRecord, with this query I just mocked. I then call the onDiComplete() for execution and finalize with some assertions to make sure everything ran smoothly. So there you go, with a few lines of MockBox and testing, you can now be on your way to smoother and pain free testing. So go forth and Mock the Box!!

I am proud to announce another addition to our ColdBox Platform: MockBox.  MockBox is a companion package to the ColdBox Platform that will give you advanced mocking/stubing capabilities; hence a Mocking Framework. Not only does it integrate into the ColdBox unit testing framework powered by MXUnit, but it can also be used as a standalone mocking/stubing framework for ANY type of stubing/mocking you would like to do outside of ColdBox application, in any ColdFusion application.  First of all, I want to thank Brian Kotek for his inspiration, and the MXUnit "locos", Marc Esher and Billy Shelton.  These guys are excellent and their contributions to the ColdFusion Community have changed the way I develop.  I had the privilege of talking to them at CF.Objective this year and discussing mocking and testing, so thank you so much guys for all the ideas and for the hard work, you guys truly rock!!

MockBox version 1.0 Beta is now on SVN and can be downloaded by downloading the ColdBox Nightly Build found in our download area.  Also, in tradition of always bringing you the best documentation and samples, we have our guide ready for consumption.  The documentation goes over every feature of MockBox, samples and how to use it.  So before I go over some of the features of MockBox, let me give a brief introduction of what a Mock is.

"A mock object is an object that takes the place of a 'real' object in such a way that makes testing easier and more meaningful, or in some cases, possible at all". by Scott Bain (Emergent Design - The Evolutionary Nature of Professional Software Development) http://www.netobjectives.com/emergent-design-evolutionary-nature-professional-software-development

That is a great definition by Scott Bain, direct and to the point.  So what are the features of MockBox:

The approach that we take with the MockBox is a dynamic and minimalistic approach. Why dynamic? Well, because we dynamically transform target objects into a mock form at runtime. The API for the mocking factory is very easy to use and provides to you a very simplistic approach to mocking. So what can the mock factory do for me?

• Create mock objects for you and keep their methods intact (Does not wipe methods, so you can do method spys, or mock helper methods).
• Create mock objects and wipe out their methods (Wipes out the entire set of methods).
• Create stub objects for objects that don't even exist yet. So you can build to interfaces and later build dependencies.
• Decorate instantiated objects with mocking capabilities (So you can mock targeted methods and properties; spys)
• Mock internal object properties (In any scope)
• Have a method return 1 or more expected results.
• State-Machine Results. Have a method recycle the results as it is called consecutively. So if you have a method returning two results and you call the method 4 times, the results will be recycled: 1,2,1,2
• Method call counter, so you can keep track of how many times a method has been called.
• Method arguments call logging, so you can keep track of method calls and their arguments as they are called.
• Ability to mock private/package methods
• Ability to mock exceptions from methods or make a method throw a controlled exception.
• Ability to change the return type of methods or preserve their signature.
• Ability to make methods return results according to argument signatures

So there you go, this is MockBox in a nutshell.  So get to it, download it now, read the guide and enjoy your testing via MXUnit.

We are kicking off our ColdBox Alliance Program with the company Computer Know How.

Computer Know How was founded in 1997 as a resale and consulting firm. At Computer Know How, we understand that technology is changing faster than most of us are able to keep up with. That is why we have a team of system analysts, programmers, network engineers, and web designers ready to assist you with handling major technical projects on time and on budget, or to simply answer your questions.

So what is the ColdBox Alliance Program? The Alliance program is a network of professional companies that are ColdBox experts and can offer support, development and other professional services on the ColdBox Platform.  They also have a tight relationship with us (the authors of ColdBox), so they get a unique insight into the development and capabilities of the platform that nobody gets.  So it is our privilege that Computer Know How was decided to become our very first Alliance Partner.  Here is their bio and description page.

Welcome to our Alliance, Computer Know How!!

After some great conversations in the ColdBox forums, I got inspired and whipped up our next version of our GroovyLoader project, part of our projects pack that you can find in our extras download.  This version includes several updates like it sports a new interceptor called GroovyStarter that you can configure in your coldbox.xml and the entire groovy environment will wrap itself and become available in any coldbox app.  Not only that, but now you can also add any amount of java library locations and the plugin will java load them at startup into your application.  These libraries can be Spring, Hibernate, Apache Commons, etc.  And to top it off, we also added the ability to groovy load one or more paths to the loader.  Before you had to configure the groovy class path to one single location where groovy scripts/classes could be found.  Now you can do as many as you like and the loader will try to find it in any of those locations.  Pretty Snazzy!! Finally, what good is a project without documentation, so we now have the project fully documented: http://ortus.svnrepository.com/coldbox/trac.cgi/wiki/cbGroovyLoader For those that do not know what you can do with ColdBox's GroovyLoader project, here is a simple list:

• script in groovy in any part of the coldbox lifecycle using <groovy:script> tags
• binding of variables between the groovy language and coldbox
• ability to load groovy scripts
• ability to load groovy classes with complex relationships
• ability to load java libraries alongside groovy classes
• no need to tweak the server or configure the server for operation
• much more...

Look how hard it is to add groovy language support to a ColdBox App: <!-- Groovy Starter: Creates & configures the GroovyLoader -->
<Interceptor class="${AppMapping}.plugins.GroovyLoader.GroovyStarter">
<!-- Paths that hold groovy libs -->
<Property name="groovyLibPaths">/${AppMapping}/model/groovy</Property>
<!-- Paths that hold jar's for us to load automagically -->
<Property name="javalibPaths">/${AppMapping}/model/lib</Property>
</Interceptor>

I have been debating with the decision to continue to support ColdFusion 7 in the main ColdBox core for version 3.0.0 and move ahead with CF8 compatibility. As of now, we have decided to maintain ColdFusion 7 support, but you can make this change. Our upcoming version is targeted for release by Fall of 2009 and we need your input. We have put together a small survey below and according to the community's response, we will either maintain the core to be ColdFusion 7 compatible or move ahead and have the core be ColdFusion 8 compatibility and above. This includes all CFML engine vendors of course. This survey will determine the development course of the platform. This software is for the community and SHOULD be directed by the community. So here is your chance!! All results will be posted here later on. I will keep this survey open for about 3 weeks.

This is only for versions 3.0.0 and beyond. This would not affect the current versions of 2.6.3.

TRACK RESULTS

If you guys attended my ColdBox: More Than MVC session at CF.Objective, please fill out this short survey so we can be invited again and participate in such a great conference.  Again, if you missed the session, you can view the online presentations here and get the source code.