Tuesday, June 02, 2009

Test Driven Development

So I posted an entry a little while ago... ok perhaps it was more of a rant about unit tests.

I don't disagree with the post, however I have learned a little bit more about testing.  Specifically what testing is and what it is not.  I recently was able to attend a JUnit class that was given by J.B. Rainsberger.  He also authored the JUnit Recipes book it really is a good book and worth the price.

Some of the things I have taken away from the class is that unit testing pretty much sucks.  However, behavior driven design is pretty cool.  Unit testing (IMO) is going through code (usually code that exists prior to the test being written) and writing a test to figure out how the code works.  This is a very effective way to trouble shoot existing code but is a very large effort, both in time and mental CPU cycles.

Behavior Driven Design is a technique that lets developers take an abstract concept (or a problem) and get it into code.  Testing frameworks like JUnit and JMock are helpful tools to do this with but don't get confused you aren't testing anything.  You can't test anything because the code doesn't exist yet - you are modeling the behavior you want your code to exhibit.  This is a powerful technique and I have done it many times on many projects but I never had a name for it.

I recently implemented a restful webservice using a new java framework called cxf.  I was itching to try out the techniques of Behavior Driven Design that J.B. showed us .  Unfortunately, I didn't have a good understanding of cxf so I was unable to use BDD effectively for quite a while.  I fell into the difficult place that java developers fall into of iterating over configuration changes and server restarts.  This is an important point not all of our efforts as developers can be boiled down into writing test cases or even BDD.  In fact, I did try to do some BDD work prior to getting the frameworks working but ended up throwing all the code away. The cxf framework changed how I thought the code would eventually work.

If anyone is interested I'll post some code examples of how the code ended up looking.  But the point I am trying to make is that doing Behavior Driven Design, although leaves a whole lot of unit tests lying around as artifacts of the process that is not the goal.  Unit testing on the other hand is an extreme effort that we do as either a last resort or as an ego trip to get our testing coverage up to 100%.

Don't confuse behavior modeling with unit testing - they are worlds apart.



Monday, June 01, 2009

It's been a little while

So with all of the fancy iPhone, AppEngine, GWT, Android development I've been involved with I was on the job the other day and someone asked me how to do something in Javascript.  Her problem was a tricky one but it basically built upon a very simple foundation.  When a user selected something she needed some text and a style to change.  I knew immediately how to do it but the syntax escaped me for a bit so I thought I'd stick it out here for the next time I needed it.

The problem is pretty simple click a button change some text and the color of the text.  So here is my very simple solution.


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
   <title> Switch </title>
      <script type="text/javascript">
         function change()
            var styleClass = 'required';
            var textValue = 'Else'
            if (document.getElementById('sigDate').className == 'required')
      <style type="text/css">
            color: RED;
            color: BLUE;
      <input type="button" value="Switch" onclick="change()" />
      <div id="sigDate" class="standard">

Like I said a very simple solution to build a very complex solution upon.