My MXUnit TDD Perspective in CFBuilder (or CFEclipse for that matter)

First things first, if you are not doing Test Driven Development yet you should at least give it a try. Sparing all the technical aspects of why its good, its just a fun way to code.

In order for you to understand why I have my perspective setup this way for TDD a quick explanation of what TDD is in order. The basic principal of  Test Driven Development is to write unit tests before you write your implementation code.  For instance, if I wanted to write a function in an Account object to test if a username existed I'd start by writing a test called something like "TestIsUsernameUnique" in a CFC Called TestAccount.cfc.  Once that test is written it is run and should fail since the IsUsernameUnique method has not been implemented yet. This is an important step in TDD, if that test passes there is certainly something wrong with the test itself.  Once you have seen the test fail the implementation code (the actual IsUsernameUnique function) is written and the test is run, and re-run until the test passes.  

One great way to learn TDD is to watch TDD Kata's.  These are screencasts of people doing live test driven development.  I've always learned best by example so watching TDD Kata's has been invaluable to my learning of TDD.

Now that I've gotten that out of the way lets talk about how I have my development environment setup for Test Driven Development.   When I'm doing TDD there are 4 things that are important to me: 1 - my UML diagram, 2 - the Test code, 3 - the implementation code, and 4 - my MXUnit view.   Additionally I like to have my outline and console views handy so I can get a quick glance of what functions are in in the code I've written.

The first step in creating my TDD perspective is to minimize the navigator view and get rid of every other view.  This might be a good place to point out that you can always reset your CFBuilder or CFEClipse perspective back to its default state by going to Window -> Reset Perspective. The following image shows what my default ColdFusion perspective looks like before I clean up the screen:

This is what my perspective looks like after I clean up my screen:

Now that I have a blank canvas lets get my workspace setup for Test Driven Development. Assuming that you have the MXUnit eclipse plugin installed, open it by either clicking on the MXUnit icon on the top toolbar, or by going to Window -> Show View -> Other -> MXUnit -> MXUnit.  By default this should open on the right side of the screen as shown:

This isn't the ideal location for TDD so I'll move it to the bottom of my screen by dragging the tab towards the bottom of the screen until the outline fills the width of the eclipse screen and dropping it there as shown here:

This is useful when using TDD for a few reasons.  First you get more real estate to read the "Tag Context" of the MXUnit view so you can see exactly why your tests are failing.  Second, as you'll soon see I need all the horizontal real estate as I can get for my code.  

Once I have my MXUnit view anchored on the bottom of my screen I'll also do the same process to add the Outline and Console views next to my MXUnit view on the bottom.  I add these tabs because I like to be able to see what functions are available in the file I am working on to make sure that the function names in my test code and in my implementation code are the same.  I also like to see what MXUnit is doing behind the scenes in the console.

Now for the important part, the code.   If you haven't already created your implementation and test cfc's, use the Navigator (which was minimized so you'll need to click on the Navigator icon on the left of the screen to see it) to create them.  Now you should now have two code editor tabs open in your editor, one for your implementation code and one for your test code.  The next step is to get both of these files to display right next to each other.  Personally I like my test code to be on the right and my implementation code to be on the left, but the order really doesn't matter.  To do this grab the tab for either your test code or your implementation code and drag it towards the left side of the screen until  the outline fills half of your editor area and drop it there. The final workspace should look something like this:

Now you can see your test code, test results, and implementation code all on the same screen and are ready to become a TDD ninja.

One last step is to save this perspective so it's readily available for your TDD development.  Go to Window -> Save Perspective As and enter a name for it.

Three Helpful ColdFusion Buider Tips

Here are a few quick tips to help increase your productivity using ColdFusion Builder. 


1) Use Ctrl + Click Shortcuts

When creating an object, using a cfinclude statement, or calling a function mouse over the object, template, or function call and hold down Ctrl key to activate a hyperlink for that definition.  While holding down the ctrl key left click the hyperlink to open the file in a new editor tab. This comes in really handy when tracking down a problem.  

Creating a Component:

Using a cfinclude:

Calling a function:

2) Start your development server from CFBuilder

Assuming that you've added your development server to the Servers View in Builder, always use the Server View to start your ColdFusion server instance.   This will bind the console view to your server instance and allow the server to display valuable information in the console.  Here is a quick example of the binding in action.   

Note: This will only work if you do not have the option "Use Windows Service to start/stop the server" selected in your server definition.

Lets start by throwing an error when the local ColdFusion server was running BEFORE ColdFusion Builder was started:

Now lets go back into builder and take a look at the console view:

Nothing is there but a generic server is available message.   Now I will go into my servers view and restart my ColdFusion server and rethrow the error.   Now the console view gives us some valuable information about the error that just occurred:

This gets even more helpful as your errors get more complex because the console view will show you the entire java stack trace.

3) Use the SQL Editor (This is not the same as the RDS Query Viewer)

The SQL Editor is a very different animal than the RDS Query Viewer.  The SQL Editor can be opened by clicking Ctrl + Alt + S or by right clicking in the code editor and selecting SQL Editor. The SQL Editor in CFBuilder will allow you to edit your query, preview your results, and insert the SQL code back into your template.  The biggest difference between the SQL Editor and the RDS Query View is that the SQL Editor will provide you with SQL Code insite!   

 

My Favorite Things In ColdFusion Builder

After I read Sam Farmer's "5 Things I Love About ColdFusion Builder" article I started to think about why I love ColdFusion Builder so much. To put it in perspective exactly how much I love it, I told my CTO I'd be willing to have them take money out of my paycheck to purchase it if my company wouldn't outright buy it for me.  FYI they did end up purchasing it for me.  With that out of the way here is why I love ColdFusion Builder:

Debugging Perspective 

This has to be one of the most helpful tools for me in Builder.   I love the fact that we can now do line debugging and view variables in real time.  Most (but not all) of the time it sure beats the old cfdump cfabort method of debugging.  My only gripe about the line debugger is that it tends to run a bit slow.  The documentation states that using the "Step Over" command over the "Step Into" command will improve performance, however, this isn't very helpful when debugging a complex OO project.  


Ctrl+Click Shortcuts

When  I first read about the ctrl+click I had no idea how much I'd use it.   For those of you who don't know about it, when you create an object or include a file you can hover over the object definition or the file location and hit ctrl-click to open that file or object in the editor.  


Servers View and the Console View

I use these features hand in hand most of the time.  As long as your ColdFusion server is started using Builder, the console is very helpful when debugging, is most cases you get the full stack trace of the problem..  I also love the fact that I can open up my administrator and server monitor right in the Builder interface instead of having to switch to my web browser.   

CFC Method Insite

Even though our ColdFusion staff is small I still have have to frequently consume objects written by other people.  Because of method insite I don't need to know the method names or arguments of the public interface of an object before implementing it.  All I need to know where the CFC lives and CFBuilder will tell me what I need to know when referring to that object. 

While I this is definitely one of my favorite things about ColdFusion builder, it is also one that provides me much frustration.   For starters it doesn't work when you pass in an object as an argument to a function.  Second it seems somewhat hit or miss for me when inside a cfscript tag.  I haven't been able to track down exactly where and why it fails but I think it has something to do with error parser.    

Extensions

Last but certainly not least is the support for custom extensions written in ColdFusion!  What a brilliant idea, allow the community to enhance your product by extending it with the language we all know and love.   I can't wait to see what extensions the community is going to come up with.  I'll definately be keeping my eye on Ray Camden's ColdFusion Builder contest.