Blog

This is a quick guide to showcase a cool new feature in ColdBox 3.0.0 that helps you create routes based upon your own regular expressions and needs.  Before (coldbox < 3.0.0) you created routes with placeholders and these placeholders could be alphanumerical or numerical values.  In ColdBox 3.0.0 they can be alphanumerical, alpha, numerical, and custom.  Custom is what we are after, which makes URL Mappings in ColdBox 3.0.0 extermely flexible.  So let me pinpoint the use ...

Self admittedly, I am new to Unit Testing. It is on my list of things to learn and implement into my development toolbox and workflow for 2010. So, officially, I have begun the process using the Base Test Case ColdBox has built in and the illustrious MXUnit of course.

All my testing was working great until I wanted to test something that was using CF9 ORM/Hibernate integration.

The first issue I had was that ColdBox creates a separate application for testings. That is, the test folder has its own application.cfc defined. Well, obviously by default, that application.cfc doesn't have ORM setup, which then of course caused me not to be able to test anything that relied on or used an ORM "persistent=true" cfc or did an EntityLoad or anything like that.

So, the workaround for this issue is pretty simple.

First, open up the application.cfc in the test folder, then setup a mapping to your base application your testings. Call it whatever you like, I called my mapping baseApp.

this.mappings["/baseApp"] = expandpath('../../');

You can change the pathing to match your given scenario.

Then you need to configure orm in the application.cfc.

this.ormenabled = "true"; this.datasource = "MyDSN"; this.ormsettings = {cfclocation=["/baseApp/model/ORM","/baseApp/modules"]};

And there you have it, ORM is now configured for your testing application and you can test away.

Self admittedly, I am new to Unit Testing. It is on my list of things to learn and implement into my development toolbox and workflow for 2010. So, officially, I have begun the process using the Base Test Case ColdBox has built in and the illustrious MXUnit of course.

All my testing was working great until I wanted to test something that was using CF9 ORM/Hibernate integration.

The first issue I had was that ColdBox creates a separate application for testings. That is, the test folder has its own application.cfc defined. Well, obviously by default, that application.cfc doesn't have ORM setup, which then of course caused me not to be able to test anything that relied on or used an ORM "persistent=true" cfc or did an EntityLoad or anything like that.

So, the workaround for this issue is pretty simple.

First, open up the application.cfc in the test folder, then setup a mapping to your base application your testings. Call it whatever you like, I called my mapping baseApp.

this.mappings["/baseApp"] = expandpath('../../');

You can change the pathing to match your given scenario.

Then you need to configure orm in the application.cfc.

this.ormenabled = "true"; this.datasource = "MyDSN"; this.ormsettings = {cfclocation=["/baseApp/model/ORM","/baseApp/modules"]};

And there you have it, ORM is now configured for your testing application and you can test away.

Self admittedly, I am new to Unit Testing. It is on my list of things to learn and implement into my development toolbox and workflow for 2010. So, officially, I have begun the process using the Base Test Case ColdBox has built in and the illustrious MXUnit of course.

All my testing was working great until I wanted to test something that was using CF9 ORM/Hibernate integration.

The first issue I had was that ColdBox creates a separate application for testings. That is, the test folder has its own application.cfc defined. Well, obviously by default, that application.cfc doesn't have ORM setup, which then of course caused me not to be able to test anything that relied on or used an ORM "persistent=true" cfc or did an EntityLoad or anything like that.

So, the workaround for this issue is pretty simple.

First, open up the application.cfc in the test folder, then setup a mapping to your base application your testings. Call it whatever you like, I called my mapping baseApp.

this.mappings["/baseApp"] = expandpath('../../');

You can change the pathing to match your given scenario.

Then you need to configure orm in the application.cfc.

this.ormenabled = "true"; this.datasource = "MyDSN"; this.ormsettings = {cfclocation=["/baseApp/model/ORM","/baseApp/modules"]};

And there you have it, ORM is now configured for your testing application and you can test away.

I am preparing to release the M5 milestone for ColdBox 3.0.0 and I am really amazed at how simple ColdBox 3 is becoming not only in syntax but in principle. I am really excited about this release as it is a push forward in ALL areas of development. Lots of modularity and re-architecture has gone into the core and the results have been amazing. A speed and performance improvement of over 20-30% from 2.6.4 on same code bases have usually been seen and that is without adding the speed of engi...

I am preparing to release the M5 milestone for ColdBox 3.0.0 and I am really amazed at how simple ColdBox 3 is becoming not only in syntax but in principle. I am really excited about this release as it is a push forward in ALL areas of development. Lots of modularity and re-architecture has gone into the core and the results have been amazing. A speed and performance improvement of over 20-30% from 2.6.4 on same code bases have usually been seen and that is without adding the speed of engi...

MockBox can have many amazing uses.  One well documented use is in assistance in creating complicated unit tests insuring you are only testing one small unit of work, it can be used for many other interesting use cases.

One of the ways we find MockBox useful during our development cycle at Computer Know How is to Mock objects we haven't had the time to complete yet, but we do know what we expect as response.  This allows us to continue development without waiting for the piece of something we haven't done yet slow us down, but keep the method calls exactly as they will be in when the object is complete.

So, how do you use MockBox outside of the context of a unit test?  Well, its easy.  

Inside a ColdBox application.

//get an instance of mockbox to use for mocking things not 100% built yet inside a ColdBox app mockBox = createObject("component","coldbox.system.testing.MockBox").init();

Outside a ColdBox application.

//get an instance of mockbox to use for mocking things not 100% built yet outside a ColdBox app. mockBox = createObject("component","mockbox.system.testing.MockBox").init();

Now that MockBox is initialized, we can start mocking objects. Lets say we have a User Object that we haven't had time to build yet. Right now it looks really advanced with lots of cool properties and functions that we spent a ton of time on. Something like this.

cfcomponent hint="I am the User ORM cfc" /cfcomponent

MockBox can have many amazing uses.  One well documented use is in assistance in creating complicated unit tests insuring you are only testing one small unit of work, it can be used for many other interesting use cases.

One of the ways we find MockBox useful during our development cycle at Computer Know How is to Mock objects we haven't had the time to complete yet, but we do know what we expect as response.  This allows us to continue development without waiting for the piece of something we haven't done yet slow us down, but keep the method calls exactly as they will be in when the object is complete.

So, how do you use MockBox outside of the context of a unit test?  Well, its easy.  

Inside a ColdBox application.

//get an instance of mockbox to use for mocking things not 100% built yet inside a ColdBox app mockBox = createObject("component","coldbox.system.testing.MockBox").init();

Outside a ColdBox application.

//get an instance of mockbox to use for mocking things not 100% built yet outside a ColdBox app. mockBox = createObject("component","mockbox.system.testing.MockBox").init();

Now that MockBox is initialized, we can start mocking objects. Lets say we have a User Object that we haven't had time to build yet. Right now it looks really advanced with lots of cool properties and functions that we spent a ton of time on. Something like this.

cfcomponent hint="I am the User ORM cfc" /cfcomponent

MockBox can have many amazing uses.  One well documented use is in assistance in creating complicated unit tests insuring you are only testing one small unit of work, it can be used for many other interesting use cases.

One of the ways we find MockBox useful during our development cycle at Computer Know How is to Mock objects we haven't had the time to complete yet, but we do know what we expect as response.  This allows us to continue development without waiting for the piece of something we haven't done yet slow us down, but keep the method calls exactly as they will be in when the object is complete.

So, how do you use MockBox outside of the context of a unit test?  Well, its easy.  

Inside a ColdBox application.

//get an instance of mockbox to use for mocking things not 100% built yet inside a ColdBox app mockBox = createObject("component","coldbox.system.testing.MockBox").init();

Outside a ColdBox application.

//get an instance of mockbox to use for mocking things not 100% built yet outside a ColdBox app. mockBox = createObject("component","mockbox.system.testing.MockBox").init();

Now that MockBox is initialized, we can start mocking objects. Lets say we have a User Object that we haven't had time to build yet. Right now it looks really advanced with lots of cool properties and functions that we spent a ton of time on. Something like this.

cfcomponent hint="I am the User ORM cfc" /cfcomponent

I was working more with Coldfusion 9 ORM and found another small caveat I thought I would share.  When working with a relationship that is filtered, the implicit "has[property]", the has does not take into account the filter.  The implicit get works as expected however.  Consider the following persistent cfc...