In fact, Dan says it quite nicely– tests (or stories, baby) are:

“examples [that] tell a story about what the code does… [and] clarity of intent is found in the quality of the narrative, not necessarily in minimising duplication.”

Thus, over utilizing the DRY principle can be ineffective when it comes to testing; indeed, he makes a great point! If tests or stories are intended to serve as “executable documention” doesn’t it make sense to make them as easy to read and understand as possible?

As such, because it’s my bag, I took the liberty of pondering the depth of favored term DRY and decided that when it comes to clearly expressing intent with respect to stories (as in the case of easyb) or tests, it often pays to be WET– that is, wholly express your tactics, baby.

You see, applying WET to, say, an easyb story then yields perhaps more text, but it leaves no room for misinterpretation, man. For example, imagine a story regarding discounts (this is my touchstone example that is in danger of itself becoming dry– no pun intended either, man). The high level story is such that VIP customers receive varying discounts depending on the amount of money a particular order has– you could even require a minimum number of items too (if you were attempting to move inventory). Thus, one scenario could be:

scenario "VIP customer with 3 items, over $30 receiving 10% discount", {
  given "a VIP customer"
  and "given they have at least 3 items totaling over $30"
  when "they proceed to checkout"
  then "they should receive a 10% discount"
} 

Of course, from here, stakeholders, through a collaborative effort, realize more scenarios are possible– for instance, the VIP customer has 3 items totaling over $100– thus, a higher discount is applied. A first stab of staying WET (that is, wholly expressing your tactics, man) yields this scenario:

scenario "VIP customer with 3 items, over $100 receiving 15% discount", {
  given "a VIP customer"
  and "given they have at least 3 items totaling over $100"
  when "they proceed to checkout"
  then "they should receive a 15% discount"
} 

Reading these scenarios (which are executable, by the way!) leaves no room for missing the boat– the tactics involved are wholly expressed!!– reading them is somewhat effortless from the standpoint that you don’t necessarily need to jump around the file to gain a clear understanding of context.

If you prefer staying DRY, the story can become more concise–

before_each "a VIP customer with 3 items is assumed", {
  given "a VIP customer"
  and "given they have at least 3 items"
}

scenario "VIP customer with 3 items, over $30 receiving 10% discount", {
  given "the 3 items total at least $30"
  when "they proceed to checkout"
  then "they should receive a 10% discount"
} 

scenario "VIP customer with 3 items, over $100 receiving 15% discount", {
  given "the 3 items total at least $100"
  when "they proceed to checkout"
  then "they should receive a 15% discount"
} 

Both stories convey intent– it is just that the WET one is more clearly expressed– in the DRY example, as more and more scenarios are added (and they surely will), one needs to jump to the top to gain an understanding of the underlying assumption (that is, a VIP customer with 3 items in their shopping cart).

DRY is fundamentally a sound principle– I’m not here to deny that; however, like all good things, it can be overused without regard for a particular situation. In fact, Johann Wolfgang von Goethe (of Faust fame, baby) is quoted thus:

“The phrases that men hear or repeat continually, end by becoming convictions and ossify the organs of intelligence.”

Because it is everyone’s bag, baby, think through DRYness from time to time and realize that in some cases, it is perfectly acceptable to WET yourself (I mean, to practice WET). Can you dig it, man?

The 0.9 release has:

• Numerous IntelliJ plug-in improvements
• The easyb plugin for IntelliJ can now be downloaded directly from within IntelliJ! See http://plugins.intellij.net/plugin/?id=2916
• Various fixes and improvements addressed from issue tracking system
• Fixtures!
• More enhanced error reporting
• narrative support
• description support

easyb supports capturing additional hip information regarding stories, such as a story’s description and some detail regarding the features, benefits, and roles of a persona related to a story. For instance, the DSL now supports a description syntax that takes a String value — single quote or Groovy’s triple quote trick.

description "some description"
scenario "text"

or

description """some long description that requires
multiple lines, etc
"""
scenario "text"

What’s more, you can provide additional details of a story via the narrative syntax:

description "text"

narrative "description", {
 as_a "role"
 i_want "feature"
 so_that "benefit"
}

scenario "text"

Both the narrative and description keywords are optional and they don’t have to be used together– i.e. you can use the narrative one without providing a description. These aspects will be captured in the output (i.e. story report) of an easyb run too.

From a fixture standpoint, easyb supports both one time fixtures (before) and for each scenario (before_each). Of course, you can add tearDown-like behavior in after and after_each.

You can download the latest release from easyb’s Google code page.

Richard Monson-Haefel recently pointed me to an hip conversation with everyone’s favorite disco superstar, Ted Neward (who you may have heard blather on and on (and on!) about Scala recently) who yammers (on and on and on– in reality, only 15 minutes but they do cut him off as he’s chattering on and on and on!) about why he thinks applets effectively kicked the bucket.

Just the same, Sun hasn’t thrown in the towel! In fact, not long ago, I had the privilege of conducting a dialog with Ken Russell, a Sun engineer focused on rebuilding the Java plug-in. According to Ken, applets aren’t dead yet and are a compelling platform for building Rich Internet Applications.

Both conversations are appealing in that they shed some light on the lessons learned about Sun’s initial applet bet and where the future may be headed (regardless if applets will be with us or not). For me, I’m not sure applets are dead just yet– Ken gave me reason to believe otherwise. Have a listen to both Ted Neward and Ken Russell and decide for yourself, man!

In this conversation, Ted explains what functional programming is and why people should care– he’s got some interesting thoughts regarding OO languages versus functional languages and more importantly, where each paradigm is a good fit. Scala’s definitely got some interesting features– if you are curious to hear them, then have a listen, man!

“separates a data resource’s [hip] client interface from its data access mechanisms”

meaning that clients to a particular domain object were shielded from the actual implementation of communicating with a particular database. Provided that clients worked with the interface type, implementations could be switched out (the database could migrate from DB2 to Oracle, for instance or one DAO type could leverage Hibernate, another IBATIS). This pattern had the bogue consequence, though, of logically dividing up a data layer into two types– DAOs and individual domain objects.

For instance, if you had a copasetic Customer domain object, you would also have a CustomerDAO interface type– your Customer object would essentially be a struct and the DAO type would handle CRUD (create, read, update, delete) operations. If you needed to find a particular customer, you’d ask the DAO type, for example, invoking the findCustomer(long id) method on the CustomerDAO object, which would return a fully populated Customer object.

This pattern seemed well and good at the time– I admit to using it extensively on a large project ages ago (after disco though); however, after a while it seemed to be a lot of work– if, because it was my bag, I wanted a Customer object, why did I have to ask the CustomerDAO for it? Why couldn’t I just ask the Customer itself? On top of that, if I wanted to create a new Customer, I had to first populate a Customer object and then pass it to the DAO type and invoke the create method.

I’m sure at the time a lot of smart people eschewed this uptight pattern and designed more natural domain objects; but for me, the tides changed when I read an interesting article about Naked Objects and then looked deeply at Rails (and subsequently, Grails) as they came to mature– these frameworks have no notion of a DAO type– your domain object (Customer) does everything for you– you can create new Customers, save instances, find instance, etc.

I recently found myself building a domain model in Java without the luxury of Grails or GORM; however, I did employ Hibernate and Spring. My initial effort starting going down the traditional DAO-domain object pairing but I quickly found myself disgusted– as a result I started playing around with combining the duo into something as hip (and polished) as what Grails/Rails would give you. My goal, of course, to provide a domain object that handled everything rather than having clients of the domain object have to work with two different trippin’ objects.

In the end, I still have two different objects and an interface type to link them (via Spring); however, clients need only work with one hip type– the domain object. My domain objects support instance methods like create, remove, and update and class methods for find-like methods.

I nonetheless still have a DAO object– it’s essentially a Spring wired HibernateTemplate– this object supports the true CRUD logic and is directly bound to Hibernate. For example, given a Race domain object, the DAO looks like this (minus some instance and class methods, but you’ll get the point):

class RaceDAOImpl implements RaceDAO {
 private SessionFactory sessionFactory;

 public RaceDAOImpl() {
  super();
 }

 public void setSessionFactory(final SessionFactory sessionFactory) {
  this.sessionFactory = sessionFactory;
 }

 public void create(final Race race) {
  final HibernateTemplate tmplte =
     new HibernateTemplate(this.sessionFactory);
  tmplte.save(race);
}

//...

public Race findByName(final String name) {
 final HibernateTemplate hibernateTemplate = new HibernateTemplate(this.sessionFactory);
 return (Race) hibernateTemplate.execute(new HibernateCallback() {
   public Object doInHibernate(Session session) throws HibernateException {
    return session.createQuery(
    "from ... name = ?")
    .setString(0, name.trim())
    .uniqueResult();
   }
  });
 }

//...
}

Note that this class isn’t public– it isn’t intended for outside consumption– the only client to this class (which will be shown shortly) is the domain object (which lives in the same package).

With this DAO object, I extracted an interface type– RaceDAO. This interface is the link between the domain object (Race) and the DAO (that is, the domain object will work with the interface type not the implementation or because it’s everyone’s bag to describe things in terms of coupling– the domain object is loosely coupled to the DAO implementation).

interface RaceDAO {
 Collection<Race> findAll();
 Race findById(long id);
 Race findByName(String name);
 //...other finders...
 void create(Race race);
 void update(Race race);
 void remove(Race race);
}

The domain object (which clients rely on) then relies on Spring (which basically acts as a factory) and composition to expose instance and class methods that indirectly (i.e. delegate via composition) leverage Hibernate to manipulate persistence.

For instance, the Race domain object looks like a normal, hip domain object– it contains various properties (and consequentially getters and setters) related to races (races have runners and results, etc) like so:

public class Race {
 private long id;
 private String name;
 private Date date;
 private double distance;
 private Set<Runner> participants;
 private Set<Result> results;
 private String description;

 //.....more to come
}

The next step could have unfolded in a number of different ways; however, I kept on truckin’ and ended up with something that works– there are certainly pros and cons associated with my choices though (I will point those out shortly).

The DAO interface is linked via Spring in a static block in the domain object like so:

private final static RaceDAO dao;

static {
 ApplicationContext context =
   new ClassPathXmlApplicationContext("spring-config.xml");
 dao = (RaceDAO) context.getBean("race_dao");
}

Note that the type in the domain object is the interface (RaceDAO) not the implementation — Spring is returning some type that is bound to the String race_dao, which in my case is the Hibernate template type shown earlier.

Thus, because the RaceDAO is a static type, I can then expose a series of class methods on the domain object for finding particular race instances like so:

public static Collection<Race> findAll(){
 return dao.findAll();
}

public static Race findById(long id) {
 return dao.findById(id);
}
//...others...

Plus, instance methods on the domain object also delegate to the interface type:

public void create() {
 dao.create(this);
}

Now clients of a particular domain object don’t need to handle or work with various copasetic objects– they work exclusively with a domain object (much like you would in Grails, for instance). For example, the following easyb scenario demonstrates the behavior of a Race instance:

scenario "Race should support finding races by name", {

 when "the find by name method is called", {
  race = Race.findByName("Leesburg Marathon")
 }

 then "the race should have 100 runners", {
  race.participants.size().shouldBe 100
 }
}

As you see in the Groovy code above, the findByName method is a class method– it returns a Race instance, which clients can then work with.

Instance methods on the domain object work too, for example, creating a new race instance and persisting it is as easy as invoking the create method:

scenario "the domain object should faciliate creating new instances", {
 given "a new race is created", {
  new Race("SML 10K", new Date(), 6.2,
     "race the hills of Smith Mountain lake").create()
 }
 then "the domain class should actually find it by name", {
  race = Race.findByName("SML 10K")
  race.description.shouldBe "race the hills of Smith Mountain lake"
 }
}

As I mentioned earlier, there are some bogue disadvantages to this strategy– that is, because it’s its bag, the static block forces clients to load some instance of the DAO– without mocking that instance out, the domain object becomes somewhat heavy. For instance, loading the Race class with a Hibernate wired DAO means that a database must be up and running. Thus, without some mocking of the DAO interface type (and subsequent wiring of Spring) these domain objects can be hard to truly unit test.

The advantage of this strategy is that clients don’t have to deal with a DAO type– they have a more neat-o-natural interface to work with– that being the business object itself (i.e. Customer or Race or Runner, etc). There are still two objects (and a binding type) to work with; however, the DAO is hidden. And in keeping with the spirit of the original DAO pattern, implementers are free to create varying instances of the DAO (should they actually need more than one– unit testing certainly comes to mind for a need to create at least one other instance).

The data models offered by frameworks like Grails and Rails are pretty hippingly sophisticated as well as elegant; what’s more they are easy to learn and natural to use. At this point, however, GORM (Grails magic data layer sauce) isn’t available as a stand alone project for Java developers; consequently, hip developers are left to rolling their own models (which leverage Hibernate, JDBC, IBATIS, etc), modeled after said project’s elegance.

The DAO pattern as it was authored (and implemented) back in the day is heavy, man; however, by applying a bit of Spring (or some other IOC framework) and leveraging a restrictive class modifier (to thus hide objects from clients), you can create more natural domain objects that still live up to the promised flexibility of the DAO pattern. Can you dig it, baby?

I had the pleasure of chatting with John for JavaWorld’s Java Technology Insider before the book was published and we had a lot of fun discussing Maven 2, JUnit, Hudson, and a host of other tools. John’s got a great deal of knowledge regarding these and other tools– all you have to do is see that the book is 900+ pages to figure that out!

Have a listen to “John Ferguson Smart on Java Power Tools” and don’t forget to pick up a copy of his book– it’s a vade mecum for anyone serious about producing working software effectively.

Andrew has some copasetic thoughts to share regarding Eclipse, NetBeans, and everyone’s favorite, for pay no less, IDE: IntelliJ; plus, Andrew muses about RAD, JBuilder, and Oracle’s JDeveloper. I am a recent convert to IntelliJ, and the conversation was rather influential in convincing me of giving IntelliJ a try.

Have a listen to “Andrew Binstock rounds up the Java IDEs” and see if you agree with him, man.

One of my favorite points Venkat makes is:

Simplicity is critical to the success of a DSL. A person familiar with the language’s domain must easily understand it.

He goes on to add:

Creating a good DSL is like cooking a nutritious meal; just like you want kids to eat vegetables without realizing and fussing over them, you want clients to use your DSL without worrying about its syntax.

Because it’s their bag, this notion of simplicity has been a guiding principle for the easyb team; yet, striving for clarity, conciseness, and expressiveness (other points Venkat goes on to make) within a DSL is harder than you think! You only need look at a classic make file to see, in my opinion, a DSL that creates a lot of fuss, baby.

Check out Venkat’s copasetic article and while you are at it, don’t forget to check out easyb, man!

• Unit tests are not integration tests- John’s got a handy technique for categorizing tests via Maven 2.
• The Handiest Java Book in Years.- Speaking of John, my friend Andrew has a stellar view of John’s latest book, Java Power Tools. I couldn’t agree more with you, Andrew!
• Is the popularity of unit tests waning?- Speaking of Andrew, he’s got a great post here with a lot of insightful comments. Well worth the read, man!
• Automation for the people: Pushbutton documentation- Paul Duvall’s got a hip article here, baby.
• When To Use Mock Objects?- This is a good read– I tend to eschew mocks; thus, when I do use them they are worth the effort and provide a good deal of handiness.
• 5 Things Grady Booch Has Learned About Complex Software- I’ll add three more:
  • complex software is hard to test
  • complex software is hard to change
  • complex software is hard to kill