pretty print your behavior

Posted by Ken Brooks Sun, 21 Sep 2008 00:00:00 GMT

Our favorite BDD tool is about to get some upgrades that give you that warm fuzzy feeling inside. Just like waking up on a cold winter day to the wonderful smell of baking cookies. Yummy!

Html reports you say? Well hello Mr. Fancy Pants!

All the goodness you’ve come to love about the existing easyb reports have now come to life in living color. In order to enable them, you’ll just need to configure another report in exactly the same way as other reports.

via ant in your easyb task: 

<report location="target/easyb-report.html" format="html" />

or on the command line: 

c:>java org.disco.easyb.BehaviorRunner my/path/to/MyStory.groovy -html ./target/easyb_report.html

Currently available are a Summary, Specification List, Stories List, Specification List Plain, Stories List Plain.

The Summary you saw just above. It will show you an overall summary, and summaries at the specification and story level. Any failed behavior count will be highlighted in red and pending behaviors will be highlighted in a wonderfully peaceful reminder color of purple.

The Stories List provides all of that that but takes it a couple of steps further. All of the elements of the stories (any scenarios, givens, whens, thens, etc.. ) will show up when the story name is clicked on and for any failures you’ll get an eyeful of failure messages along with part of the relevent stacktrace.

More of the same for Specifications list.

Since all we had prior to easyb 1.0 was a text only format, we got sentimental and included a stripped down, nearly text only, format here as well. Ok, so we didn’t really get sentimental, we actually thought this is really where the rubber meets the road when it comes to bringing stakeholders and developers together. As part of your build you can now publish these reports and share them with those interested parties. Makes BehaviorDrivenDevelopment truly, uh, easy!

All of this and more is waiting for you in easyb 1.0. Just like those tasty warm cookies, its still in the oven and I’ll bet you can’t wait to get your hands on it.

Keep an eye on the following sites for more announcements about the availability of 1.0.

Posted in  | Tags , , , ,  | 1 comment

Simplicity and Consistency (Part 1: Simplicity)

Posted by Ken Brooks Fri, 25 Jan 2008 00:20:00 GMT

Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius—and a lot of courage—to move in the opposite direction. —Albert Einstein

This speaks volumes. The mission statement for the group I’m part of at work is ‘Simplicity, Consistency’.

Simplicity is difficult. It is probably the hardest thing to achieve in development.

A developer usually goes thru a maturity process in stages. See if any of this sounds familiar.

  • Developer produces very little code. They struggle to get anything done
  • Developer produces alot of code as they become familiar with the language of choice
  • Developer produces alot of code but now does it fast!
  • Developer produces the right solution in very little code.

Q: Why would I want to spend time simplifying if I can rip thru the code at lightspeed?

A: The code you are writing is probably going to be around alot longer than you think. That means that many people will probably have to open it up and understand it. The less lines of code you write, the less they’ll have to digest and the meaning of the code is usually not obfuscated. (Now, to be fair, I’m not saying that making code terse for the sake of being clever is a good thing. That is probably my biggest gripe with perlisms. They are terse at the expense of clear meaning.) The easier it is to understand, the faster you can change it and the likely hood that your changes will be successful will go up.

In my years of development one thing remains quite constant. It usually never fails that when a challenge is presented, the best answer invariably turns out to be the simplest. However, its usually the hardest to arrive at.

So next time someone tries to use lines of code written or some other ‘objective’ way of measuring your developer and codebase maturity perhaps you should rebut that you value those that spend more time on less lines of code than less time on more lines of code. It will save you time and money in the long run.

Tags ,  | no comments