The Disco Blog Welcome Guest | Login or Register

Been busy, man. Sorry for the delay!

• Pair Programming vs. Code Reviews- Pairing helped create easyb in short order.
• Bugs Kill Productivity and Schedule Accuracy- It’s all about speed, baby.
• Industry Seeks Software Testing Breakthrough- Can they do it?
• Unit Testing: Avoiding Extremism- Wow, interestingly put, man.
• Rewrite or Refactor?- More often than not, it seems people prefer to rewrite– even with 80% coverage.
• Communicating with Business Using FIT and FitNesse- “People mostly use Fit for test automation, less for communication.” I hadn’t thought about it that way.

Behavior driven development has been my bag lately; in particular, I have found the subtle shift in thinking in terms of behavior easier than that of tests. By thinking about behavior (which is, in essence, the specification of a hip object, for example), it becomes easier to validate things early-– in fact, when thinking in terms of a specification, it becomes copasetically easy to write things upfront. What’s more, one exceptional BDD framework, RSpec, has a remarkably hip DSL that reads like plain English, making the whole process easy (and fun).

Seeing how easy BDD is with RSpec inspired me to explore some similar options in Java– specifically, I teamed up with some hip friends and leveraged Groovy to create a flexible DSL for defining behaviors. The result is a framework dubbed easyb, baby.

easyb specifications are written in Groovy and are run via Java (currently, the command line or Ant); what’s more, easyb supports a few different styles of specifications ranging from RSpec’s copasetic it to a more story based DSL with disco givens, whens, and thens. The end result is a groovy framework that allows you to easily verify the behavior of normal Java objects, applications, packages, etc. Check out easyb today and see just how easy it is, man!

Many thanks to QualityLabs.org for hosting easyb– don’t forget to subscribe to the RSS feed to keep up with the project (and stay in the groove too)!

IBM developerWorks recently published a tutorial, written by yours truly, man, entitled “Spot defects early with Continuous Integration” — because it’s my bag, baby, this hip tutorial guides you step-by-step through the fundamental concepts of Continuous Integration using Hudson, Ant, and Subversion– when you’re done readin’, you’ll understand the copasetic benefits of Continuous Integration as well as how to set up and properly configure Hudson, Ant, and Subversion to work together. The resulting build process will run both tests and software inspections and will report back bogue violations almost as quickly as they occur, man.

If you are the slightest bit curious about Hudson, I recommend you read this tutorial as I go over just how easy it is to install, configure, and start disco dancin’ — what’s more, even though the tutorial assumes Ant and Subversion as the build tool and repository, you’ll see that you can easily plug in Gant or Maven, CVS or ClearCase, etc if that’s your bag. Dig it?

In keeping with my copasetic conversations with hip people, I recently had the opportunity to chat with my friend Neal Ford regarding JRuby. As anyone who’s met Neal knows, this cat worships Ruby– what’s more, Neal is a super smart dude that lives and breathes Java as well. Accordingly, Neal offers some interesting thoughts on JRuby (and of course, Ruby) such as meta-programming, JRuby’s future, associated tools, and even Groovy.

Have a listen to this copasetic podcast (courtesy of JavaWorld) and stay tuned for more hip chinwagging, baby!

• Boolean parameters can be evil- Well said, Alex!
• Coverage != testing- I couldn’t agree more, man.
• Writing Testable Code Is About Managing Complexity- You bet, baby.
• Value of the Build Process- Nicely written, Rich!
• Trivial Pursuit: Unit-Testing Getters and Setters- hummm, what do you think?
• Is it really a domain specific language?- Great write up, Hamlet!
• CodeGear Exec Shares Vision for Programming in 2027- Prognostication is so dangerous, but fun to do, isn’t it?

It’s no secret that hip disco dancers are a hit with the ladies; however, the big secret is that Groovy developers (or those that wish to be) are also fond of the ladies.

A few months back, I happened to check out GIA on Amazon and was amused to see some groovy data-mining in action.

You had better believe that I haven’t ever hit print screen so quickly, man!

I’m not sure what’s more amusing– that fact that the iBatis book only has two stars or that the Grails book is better than the Pet of the Year?

I find it particularly hip that, of late, it seems our industry is trying hard to bridge the gap that exists between stakeholders and developers– there are some undoubtedly copasetic tools like Fit to entire disciplines like BDD, which attempt to involve non-technical people in various ways.

For example, Fit enables stakeholders to specify trippin’ business rules (or the results of them) via tables, which are then logically implemented by hip developers. BDD stresses the notion of behavior and thus tries to get developers thinking like stakeholders in a more natural manner, man.

In particular, one disco BDD framework named RSpec comes very close to a simplistic DSL that arguably non-techincal users could take advantage of. Fairly recently, people have even created frameworks for executing simple text files (which is clearly the hippest thing ever, baby). Even Groovy has a similar BDD framework dubbed GSpec, which is modeled closely after RSpec.

One thing these copasetic frameworks have in common is a DSL that attempts to make the act of verification (either through tests like Fit or through specifications via RSpec, etc) easy. Accordingly, over the last few weeks, I’ve been playing around with a Groovy based framework (targeting Java developers) that attempts to mimic aspects of RSpec and JBehave’s story framework.

As I previously noted, the it closure delegates to JBehave, thus, everything you can do with JBehave’s hip ensure-like framework, you can do in this simple DSL– what’s more, I ended up adding three more closures that facilitate the notion of a story:

• given some set up or copasetic context
• when something happens
• then ensure that something else should have happened, baby

You can use as many as you need too (i.e. a few givens and a few thens)– I haven’t figured out a good way to chain them, however, man. Moreover, as I began playing around with stories using this framework with existing projects, I noticed that stories are more user centric (no surprise); hence, the given aspect can be a bit heavy. Think about it for a second– normal unit tests rely on simple objects to verify; as these tests go up the stack, however, becoming component, integration, and system tests, the cost to set them up increases– databases have to be running, code needs to be deployed, filesystems, email servers, outside vendors all need to be accounted for (or mocked) in order to run higher level tests. The same is true for stories, if they are written from the standpoint of a smokin’ user.

Therein also lies the rub– end users, stakeholders, disco dancers, and other normal people not associated with the actual development of a system rarely understand its bowels– they shouldn’t either, by the way. This happens to be one area that hasn’t been elegantly solved– nevertheless, given that the set up of a story requires some plumbing in place (or the mocking thereof) I had to create a delegate for the given closure that facilitates putting a data-source into a known state.

One of my favorite frameworks for database seeding is none other than DbUnit– accordingly, using its hip API, I was able to create a simple delegate that requires database connection information (revision two will most likely take a live connection object too) and an associated XML document (in String form). The XML document is created in a closure, so you have a number of options. You can:

• create an instance of a MarkupBuilder to create a data set
• return a multiline String using the """ syntax
• return the text of a seed file, like new File("./src/conf/seed.xml").text

Therefore, to create a groovy story, man, you can do this:

import org.springframework.context.support.ClassPathXmlApplicationContext

given "the database is properly seeded", {
 database_model("org.hsqldb.jdbcDriver",
  "jdbc:hsqldb:hsql://127.0.0.1", "sa", ""){
    """<?xml version='1.0' encoding='UTF-8'?>
   <dataset>
    <widget widget_id="1" type="drink" bnncd="hops"/>
    <line_item line_item_id ="20" widget_id="1" scne="789"/>
    <line_item line_item_id ="21" widget_id ="1" scne="33"/>
   </dataset>
   """
 }
}
//and
given "the DAO instance has been obtained from Spring", {
 context =
  new ClassPathXmlApplicationContext("spring-config.xml")
 dao = context.getBean("widgetDAO")
}

when "findWidget is called with a valid id", {
 wdgt = dao.findWidget("1")
}

then "a working Widget object should be returned", {
 ensureThat(wdgt, isNotNull())
 ensureThat(wdgt.getLineItems().size(), eq(2))
}

You can run these stories two different ways– either command line like so:

java org.disco.bdd.SpecificationRunner ./src/story/org/acme/MyStory.groovy

Or via Ant, like so:

<specificationrunner>
 <report location="${tareget}/report.xml"/>
 <behaviors>
  <fileset dir="${loc}/stories" include="**/*Story.groovy"/>
 <behaviors>
<specificationrunner>

The gap that exists between those that define requirements and those that write them hasn’t been bridged quite yet; however, we appear to be reaching that goal one hip iteration after another– in a perfect world, our customers would write the tests or at least tests could be generated by reading the requirements as written. I do believe that the story format demonstrated above does get us trippingly close– stakeholders could potentially write these or at least read them, no?

Using a little Groovy magic influenced by some spectacular frameworks, I think we are one step closer though. Dig it?

Incidentally, if it’s your bag and you want to play around with this simple behavior-story framework, you can download a snap shot of it. Please note that the distribution doesn’t have any documentation so you’ll have to read these posts until we write something up:

• Executable documentation the easy way
• Go easy with specifying behavior, man
• Internal DSLs, Groovy style

The distribution just includes a hip jar file (easyb-0.x.jar) and a few related runtime dependencies– if you don’t use the DbUnit given seeding stuff, then you can exclude the DbUnit and Crimson jars.

Jeffrey Fredrick of Agitar (and of course, CITCON and CruiseControl fame) and I will be hosting free webinar on how to implement a successful continuous integration and testing process. Jeffrey is a super hip guy and I’m really excited to have an opportunity to team up with him– if you’re curious about CI, developer testing, disco music, or are looking for something interesting to do for roughly 60 minutes, then join us!

Because it’s my bag, here are the details, man:

• When: November 14th, 9am PST (which is noon EST and 5pm in the UK, for those who are time zoned challenged, like myself)
• Where: Your desk, internet enabled refrigerator, or iPhone
• Why: Because it’s your bag, baby

Registration is required for this webex event.

As if seeing a groovy gal shave a dude’s head and hanging out with copasetic cats like my hip friends Neal Ford, Brian Sam-Bodden, and Chris Judd weren’t enough reasons to head out to Ohio for CodeMash, I’m pumped to have been invited to present two sessions and one open spaces event.

I’ll be speaking about BDD, Groovy, and a Martin Fowler inspired subject regarding the future of build languages. My BDD talk will obviously focus on how BDD can drive development more effectively than TDD and I’ll demonstrate some JBehave, RSpec, and a Groovy inspired RSpec knock-off. My Groovy session is a veritable crash course on using Groovy quickly– 101 style, baby. Lastly, the build languages openspaces session is an open discussion regarding Ant style (i.e. XML driven platforms like NAnt and MSBuild) build platforms versus more expressive platforms like Rake, Raven, and Gant, for example.

With sessions on Castle, Dojo, Grails, Rails, Scala, CI, and myriad other hip subjects, CodeMash looks like it is going to be a blast, baby– if you’re going to be there, let me know!

It’s my bag listing this week’s bag, baby:

• False positives in JUnit- FindBugs to the rescue, thankfully.
• Release It!- I had the pleasure of meeting Michael Nygard and I can’t wait to get my hands on a copy of his work.
• Most Popular CI Servers (An informal survey)- No surprise that Hudson made the list, man.
• Atlassian Clover 2.0 Spices Up Code Coverage- Interestingly, Clover now reports “Per test coverage measurement.”
• Why do Evolutionary Design- Well answered, Pramod!
• .NetSpec- Aslak’s says this is interesting, baby.