I'm happy to announce another update to the MXUnit Eclipse plugin. This started out as an attempt to correct a deficiency that was a deal-breaker for some people, but turned into a few additional features as well. Here are the goodies. Any-resource-level CFC Path Property Several people who've tried to use the plugin have been stopped at the gates because the plugin could not correctly determine the dot-notation (CFC) path to a component. This was due to the way the plugin expected eclipse projects to be set up. When I first wrote the plugin, I knew there was one condition that would cause the plugin to not work for people... but I thought "Why the hell would anyone set up their environment that way?" I should've known... The proper fix is now in place: you can set the component root property at any resource level. This should eliminate any problems with the plugin determining the component root for a directory of tests since you can now specify that root on any folder, not just the project. In addition, there's a nifty feature contributed by a user named Alanyst that provides the "I don't want to use the webroot, but I want an 'empty' component root" behavior that some people have asked for. Method Timeouts Bob Silverberg, a dude I hold in high esteem, emailed me one day with this bugger of a problem in the plugin: it'd hang and hang and not return anything. The problem turned out to be trying to call debug() on a component instance, and it was taking forever to serialize the data across the wire from CF to Eclipse (or something like that). My response was "if it hurts to do that, quit doing that". Bob's persistent, though, and was having none of my attitude. From our conversation, the need for method timeouts was born. There's now a global preference for timeouts. Now that this feature is in there, I like it a lot. I've set my preference down real low... to 5 seconds. This keeps batches of tests flying and lets me know what tests are taking too damn long. When I want to actually run those long tests, I change the preference (quick and easy from within the View itself.. no window/preferences hooey). Admittedly, this timeout behavior is an initial stab. It's a big old sledgehammer approach (single setting controlling everything). In the future, this timeout behavior will likely be controllable at a more granular level. This was put on the radar a while ago when Bill and I started talking about what's coming up in MXUnit 2.0. Run multiple directories or components in the Navigator You should know by now that you can right click on any directory or Test component in the navigator view, right click, and select "Run MXUnit Tests". However, until now this was limited to a single directory (and its children, obviously) or component. And you couldn't select projects. This was modeled after the JUnit way of doing things. Turns out, the addition of the folder-level component path property was the key to enabling this "multiple select" feature. I won't get into the details, but the bottom line is that you can now select multiple directories, tests, and even projects. No more View "Chatter" When running a large number of tests, the top panel of the view scrolls to the bottom as the tests are run. In addition, all of the tests are selected so that the bottom panel will have any stack trace details immediately available. This visual cue that your tests are running is a holdover from when the plugin was first written, prior to using a progress bar. This was fine in normal day-to-day unit testing, but when running a lot of tests the constant updating of both panels created "chatter". On a fast machine, it was downright epileptic. With this update, the top panel no longer scrolls, and the bottom panel isn't updated until all tests are run. This creates a much quieter test run. If you mainly use the plugin for TDD, small-batch runs, etc, then the difference will not be very noticeable. If you run a lot of larger batches, you'll see the difference right away. Small stylesheet enhancements This is a small change, mostly for the bored and picky. When viewing the output of tests in the browser view, the styling was extremely basic. I'm no pixel pusher. So I made the styles customizable, with a bit of work. This will get easier down the road, but for now, simply navigate to your eclipse plugins directory, find the org.mxunit.eclipseplugin.... directory, and then drill down into the "style" directory. You'll find a stylesheet. Do as you please. Just don't delete the file. As I said, this is a silly little change for folk more visually inclined than I. So how do you learn more about all this stuff? You might not know it, but the plugin comes with integrated help. It's the QuestionMark icon to the right of the View. Click that thing, and then from there you can go to "Configure global preferences" to learn more about method timeouts and "Configure project properties" to learn more about the improvements to setting the CFC path property at any resource level, including the "empty path" indicator. The plugin's been working fine for me. Will this break things? It shouldn't... though I haven't tested on Mac or Linux. If the plugin behaves differently -- in bad ways -- email me on the MXUnit mailing list and I'll do my best to get things fixed up toot sweet. 'Cause toot sweet is how we roll. A Plea, from me to you, About Coding Faster This is completely unrelated to the plugin but is directly related to "working smarter, not harder". The MXUnit framework download comes with a directory named "cfeclipse". Inside are two directories: snippets and dictionary. Please, read the readme.txt files in there and spend 5 minutes installing the dictionary and snippets. Use the copysnippets.xml ant task to copy the snippets and the keyboard shortcuts to your snippets directory. And start using the snippets! You can crank out lots of boilerplate code with the snippets and focus your energies on writing just the code you need to write. Done. Test and Be Happy!