A First Look at L-Unit™ 2.0
For anyone conversant with Test Driven Development, it’s enough to say that L-Unit™ is a unit testing environment for Lasso code. For the rest of us, L-Unit™ is a framework upon which you can setup, store, and run tests of your custom types. These tests are abstracted from your application as a whole, and only act upon an individual “unit“. The developers say this helps you avoid the “whack-a-mole” type debugging one inevitably engages in when revising a broad or complex code-base, and I can certainly see how L-Unit™ will help.
Setting up L-Unit™
I’ve heard about L-Unit™ for years, but I never paid much attention to it until last September’s Lasso Developers Conference. So, about a month ago I downloaded a zip-archive of the application from http://www.l-unit.org/. The developers recommend checking out the Subversion repository instead, which makes a lot of sense — the zip file I downloaded was created early October, while the repository was last updated a month later — but I was being lazy. Besides, while I use Subversion daily, some developers are not yet comfortable with SVN. I plan on publishing a second article on L-Unit™ after I’ve used it a bit more, and I’ll base that second article off of the code-base checked out from the repository.
I started by reading through the first 24 pages of the manual. The last 3 pages are reference material, and can be skipped until you start coding. The “Quick Setup Guide” is on page 24 of the manual, which seems an odd location. But, it being there guided me towards reading the manual before I started, which was perhaps the writer’s intention. The “Quick Setup Guide” is available as a separate download as well.
After reading the manual, it was pretty obvious I needed to rework many of my settings in Lasso’s ServerAdmin. I had about 15 websites already running on my development machine, but rather than create a separate Lasso site for each, I had only configured the default site. This wouldn’t do, since L-Unit™ should run in a default environment. So I moved everything in under a new Lasso site instance, and created a second new Lasso site just for L-Unit™.
Starting with a clone of an example test case , I created a very simple test case for a custom type I had recently completed. This was putting the cart before the horse in the Test Driven Development methodology, but I thought I would learn a bit more this way.
Boom. I hit my first brick wall, if not a particularly high one. Belatedly realizing that L-Unit™ must parse through my class-files, custom type files in Lasso parlance, I ran a chmod command on the site’s root directory to allow write privileges for everyone.
chmod -R go+w unit
Changes to my code
I found that I needed to adjust my coding style to fully utilize L-Unit™. The custom type I had chosen had only three member tags. One of these member tags was fairly complex, but none of the enclosed-code was duplicated anywhere else. Also, the complex member tag had no return value — it simply set or modified a global variable. To test the code within the complex member tag granularly enough to make a difference, I needed to split it up into many smaller tags, and make each one return some value. While this might seen a bit intrusive on the part of L-Unit™, I think the end result is a better bit of coding on my part than what I started with.
When I finished with my a successful test case for that first custom type, I moved onto a second. This was actually a custom tag. The test setup for a custom tag was identical to that for a custom type. Again, granularity in my own code was a must. I ended up re-coding my tag into a custom type, but just get into the mindset of building a bunch of small constructs, instead of one big one. Intrusive? Yes, but again I liked what resulted from my re-coding. And, I didn’t actually change the usage for the resulting code.
Finally, when I created my first test for this second custom type, I was at first a bit confused. I code all of my custom types and tags for a given namespace within a single file. So, naturally I tried coding my second test case in the same file as my first. Since the two constructs I was testing are in the same file, this made perfect sense. Well, apparently not to L-Unit™. Oh well, once I stumbled upon the answer it wasn’t a huge paradigm shift to build one test case per file.
What I don’t like
The PDF manual I downloaded doesn’t allow copying and pasting. Any such attempt results in gibberish. Perhaps I’d have better luck with Acrobat Reader, rather than Apple’s Preview. The way around this annoyance is to use the Google Doc version of the manual. I had downloaded my copy of the manual from the “Downloads” page, rather than looking on the “Documentation” page where the Google Doc version is mentioned.
I found it difficult to debug errors shown by L-Unit™ during a test run. The information returned was fine, but since each test is run asynchronously there are few if any means of pulling out more information. I’d like to see some method of viewing the content_body from each run of a tag within L-Unit™. It’s possible a construct like Log(-Window) would help push debugging information out to the Lasso Service console, but I haven’t tried this yet.
Of course, I’d like to see L-Unit not rely on non-standard file suffixes, but I’ve already detailed my reasons for this in an earlier post. It is nice to see the numerous warnings against running L-Unit™ in a production environment. But, such a warning should be for performance reasons, not security.
What I do like
The application’s user experience is very polished, which is refreshing to see in an application intended for admins. And, while the documentation has some small errors and could use a bit more information, it’s rather polished as well.
Others might complain more about the need to adjust their own coding structure to maximize the usefulness of L-Unit™, but as I said before, I liked the results. I probably should have been coding more like this for years. Of course I really should have built my test cases first, and then written my code to satisfy those tests. So changes in my architecture would have seemed more natural from that perspective.
I probably could have had any questions answered pretty quickly by posing them on the LassoTalk mailing list, or emailing the current developer directly. But I think a number of developers hesitate before asking questions, not wanting to appear the “newb”. By sorting through the issues alone, I got a sense of what they would be going through. Either that, or I just didn’t want to appear the “newb” myself.
I’m looking forward to using L-Unit™ on several upcoming projects, this time coming at the code in the correct order, with the test-cases first and the application code after. I’ll need more time to fully form an opinion, but at this stage I’m optimistic that L-Unit™ will become a standard part of my work flow.
A fews more things
L-Unit™ was originally developed by Greg Willits, and has more recently been driven by Ke Carlton. Both should be commended for their respective efforts. Ke is the one who gave the L-Unit™ presentation at last year’s Lasso Developers Conference, and finally got me to take a look at the application.
Greg Willits also developed PageBlocks™, L-Revolver™, L-Migrator™, and L-Debug™ — which I speculate might satisfy my desire for more debugging capability within L-Unit™. It’s not my intent to write about any of these other offerings at this time. This posting is intended to reflect solely on L-Unit™ 2.0.
Do you have any experience with L-Unit™, past or present? Did I miss anything, or get something wrong? Make yourself heard in the comments.