The Disco Blog

The next release of easyb will support the notion of ignoring entire stories or various scenarios within in story via the ignore keyword.

As currently coded, ignore supports two features– either ignoring the entire story all together via ignore all or you can pass in one or more scenario names which to ignore. This selective ignoring feature can take three different types of parameters– a single String (which represents the particular scenario to avoid), a series of Strings (separated by commas, which represents a series of scenarios to ignore) or a Collection of Strings (which also represents a series of scenarios not to run).

As you can see, this keyword is very much like the standard xUnit paradigm’s ignore; however, it might be a bit more flexible as you can specify just what scenarios to ignore and which to presumably run in one statement, rather than having to repeatedly issue ignore statements.

For instance, the following story, dubbed noworking.story, would be completely ignored:

ignore all

scenario "this is purposely a broken scenario", {
 given "some variable with a value", {
  val = 12
 }
 then "to force an error, one should verify it is not 12", {
  val.shouldNotEqual 12
 }
}

That is, nothing within the story would be executed; consequently, no state would be captured– nothing is pending either. As of right now, pending and ignoring stories/scenarios are completely different and also convey different meanings.

Using the same exact story, you could also specify the particular scenario to ignore by passing it its name as follows:

ignore "this is purposely a broken scenario"

scenario "this is purposely a broken scenario", {
 given "some variable with a value", {
   val = 12
 }
 then "to force an error, one should verify it is not 12", {
   val.shouldNotEqual 12
 }
}

If this same story had more than one scenario, you could then either continue passing in comma delimited scenario names or just pass in a collection like so:

ignore "this is purposely a broken scenario",
    "this is also a purposely broken scenario"
//or
ignore  ["this is purposely a broken scenario",
   "this is also a purposely broken scenario"]
//which is the same as saying
coll = ["this is purposely a broken scenario",
   "this is also a purposely broken scenario"]
ignore coll

This feature is currently considered a prototype and only lives in the tip of easyb’s SVN repository. Feel free to download the source and give it a spin for yourself (building easyb is easy, man!)!

I recently had the pleasure of chatting with Max Ross, who is one of the guru’s behind Hibernate Shards, which is a fairly hip project that aims to make horizontal partitioning (aka sharding) easy within Hibernate. As Max explains in this JavaWorld Java Technology Insider podcast, Hibernate Shards provides a unified view into any number of databases, making huge amounts of data manageable even as the system evolves.

Max is a super interesting cat and I thoroughly enjoyed this conversation as I learned quite a lot– if scalability is something on your mind, then sharding might be the answer. As you’ll hear in this conversation, scaling and synchronizing multiple databases is a fairly complicated problem to solve and the Hibernate Sharding team has done a great job with this project.

Ever since Agitar lamentably shut its doors earlier this summer, there have been quite a few postings stating, predicting, or refuting the demise of unit testing. In fact, I was lucky enough to be quoted in one hip article regarding this subject written by my good friend Andrew Binstock. In his article, dubbed “Is unit testing dooomed?” Andrew does not, in fact, reach the conclusion that the practice of unit testing is doomed– he merely suggests that there might be sufficient evidence to conclude the practice might have not caught on like most of us think has.

He states that while other languages (Python and Ruby are named) appear to have a strong following of unit testing,

there are signs that, in the Java community at least, resistance has built up against the unit testing idea.

Andrew goes on to note that, in many cases “unit testing seems to offer little value” and that “evangelism [such as TDD] has become so overbearing that it makes unit testing as a whole unappealing.” Because it’s his bag, he then goes on to make a compelling case for unit testing naming four benefits, which, for those of us that actually practice unit testing, are hard to refute:

Defects are identified nearly immediately, and because unit testing isolates their cause and effect, they are also resolved more quickly. As a result, you can be more confident in the schedule. You also get better code-level documentation.

The question remains, however; is unit testing doomed? The answer to this question, of course, depends on your point of view, baby– or more precisely, what kind of development you are currently performing. For, as Andrew noted, if you are currently practicing Agile development, where unit testing has taken a strong hold and where “developers write hundreds of small tests for exercising their own code” the answer to the former question is a resounding no!

Unit testing is thriving in that crowd– people often claim (me included) that they can’t live without it! In fact, to the multitude that lives and breathes unit testing, the subject has most likely become simply boring. JUnit, by this point, is old hat– it was super interesting almost a decade ago and when 4.0 came out it was something to chat about, but for the most part, there isn’t much more to say about unit testing in general (for evidence of this, read InfoQ.com’s posting and the subsequent comments dubbed “JUnit Still Not Dead“). Sure, few books regarding JUnit have been published lately and Google’s trends seem to indicate that no one searches on JUnit. But guess what? I don’t need anymore copasetic books on JUnit– I’ve read them and I’ve got enough knowledge now on how to properly utilize it. I have zero need to go to JUnit’s website either– there’s nothing new there. In fact, in some cases, people have moved on to other frameworks, like TestNG (at least one person, other than me, is also using easyb!).

The reality of the Java market though, is that there is an entire throng of people who didn’t (or couldn’t) jump on the JUnit bandwagon all those years ago– this crowd is largely maintaining enterprise applications that are, simply put, incredibly hard to unit test, man. In these organizations, I have found that, more often than not, this is where the battle for tried and true unit testing is being lost.

In fact, Andrew correctly quoted me as stating in response to why I don’t implement a lot of TestNG solutions for companies:

most organizations do so little unit testing, if any, that I stick with the simple, well-known xUnit tools, so as not to create confusion. Most organizations are just not ready to learn anything more than basic unit testing — if that.

Many of these companies are the entire reason why there is a Java based financial ecosystem. They are why products like Websphere exist. They are why products like JBuilder existed. They are also the same companies that companies like Agitar hoped would buy their products.

These companies employ a lot of trippin’ developers. These companies have many projects that are huge. Unit testing for these companies is like trying to eat an elephant– you can start with one bite, but the overall task is daunting! When people, who work on these projects, hear evangelists bang the TDD drum, many are left scratching their heads– “how do I write a unit test for an application that has more dependencies on external systems than I have figures on both my hands? It would take me longer to handle the dependencies than to just code the feature.” (True, there is folly in this statement, however, this statement is uttered daily across the globe, man.)

These comments and this line of thinking by people faced with maintaining these code bases on a daily basis then logically answers the question of why would someone assert that unit testing “seems to offer little value” and evangelism “has become so overbearing that it makes unit testing as a whole unappealing”– for these folks, the strict term unit testing is doomed.

Don’t get me wrong, it isn’t that unit testing is impossible for these code bases and these teams. I’ve made a career of assisting in this arena; however, this is no easy task. It takes years to effectively introduce cultural change that can yield disciplined unit testing across an organization. In fact, in these situations, you can’t introduce unit testing alone– to effectively gain the manifold benefits of proper unit testing, you need an entire infrastructure to support it– namely, you need continuous integration, which means you need predictable builds.

Think about it for a second– unit testing is the elephant in the room. You’ve just been asked to eat it. But you can’t just take a steak knife and fork and start eating– the elephant is still alive looking right at you. No, you’ve got to first kill it, cut it up, cook it, etc. No wonder few people eat the elephant. Burger King is around the corner! No wonder unit testing often times seems doomed. We have a QA team that finds bugs!

Indubitably, these development teams are forced to rely on late cycle testing or at best, in the short term, can of course build up a hip suite of higher level tests. As a matter of fact, this is probably the best place to start! Can’t isolate that Account object for unit testing? No problem, bite the bullet and code an integration test– just make sure you realize you’ve got to handle the myriad dependencies associated with that business transaction (think a properly seeded database, etc).

As I said, if unit testing, as it is defined within the context of TDD, is an elephant for you and your organization, then it

is likely to remain a niche solution, found at organizations that really understand its value and progressively adopted by sites that can no longer stand the long debug cycles.

The answer to most questions depends on your point of view– if you are working on a team that has embraced agile principles, unit testing is alive and well. It’s a healthy practice that when questioned brings extreme consternation to those who’ve drank the Kool-Aid.

If you find yourself working on a legacy code base, your answer might be somewhat different– indeed, unit testing in these cases is not as easy as downloading JUnit and coding away. It’s a sizable elephant that a culture has to collectively figure out how to eat. And that takes time, commitment, and a lot of discipline. If you can’t get a handle on those three aspects, then yes, unit testing is doomed. Can you dig it, man?

• Web Component Testing Screencast- my friend Rod Coffin demonstrates some interesting aspects related to efficient web testing.
• Software Is Deployed, Bugs and All- does this surprise you?
• % test coverage doesn’t provide useful information- you are correct, man; in fact, code coverage is only effective at telling you what you haven’t tested.
• Java Performance Tuning: A Conversation With Java Champion Kirk Pepperdine- great quote: “Complex code tends to confuse [just-in-time compilers], so that they provide either suboptimal optimizations or no optimizations at all.” Oh yeah, not to mention complex code is a bear to maintain!
• Minimalist Coding Style- now, what would Kirk say regarding this style of coding?
• Unstable code- speaking of code, Oren’s got a brain teaser here, although “unstable” is quite a generic term and thus, might have lead to the number of different comments he received.