Michael Dowling's Whispers

This is the first part of many on how to use Spectacular, an open-source acceptance test / behavior driven development tool for development teams. This installment will focus on how to use Spectacular to create Executable Use Cases, and how those use cases can be executed using Selenese to drive a Selenium browser!

Part of why I wanted to write a tool like Spectacular is that I wanted to explore the possibility of using simplified Use Cases in the context of Epics in order to describe the overall requirement, in addition to using that Use Case to assist in creating stories during a story workshop. Of course, the one thing bugging me about the whole subject is that I would also want those Use Cases to be completely testable. Enter Executable Use Cases.

The idea works like this: Let’s say that during a story mapping workshop, an agile team identified an Epic/Activity for logging into a system as an existing user. They collaborated on a simple diagram showing how this would work:

Using this web-flow diagram as a guide, the team can now start to write a simplified use case in order to weed out some details and describe the user flow and interactions. In Spectacular, the requirement for a Use Case is to create a table with at least 2 columns (though 3 or more is typical, to describe ancillary details). The first row should be the title of the use case, with the word “Flow” in there (i.e. “Primary Flow: Log In” or “Alternate Flow: Remember Me Log In”). The next row are the column headers (“User Action”, “Expectation), followed by the use case itself. Additional columns are ignored by Spectacular:

Now that the team has written a use case, its time to make it executable. Many of the use cases I run into with my Agile teams are user-interaction based, which is what inspired me to giving user the ability to express a use case as a series of Selenese commands (in addition to writing the fixtures in Java, Ruby, and Groovy). Once the team has agreed to the use case details (and brainstormed user stories from this i.e. bad login, already logged in, etc.), the team opens up a text editor or IDE and writes the fixture in Selenese:

Flow: User navigates to system home page.
    open "/"
    waitForPageToLoad 5000

Expectation: User sees system home page with a header of "Home Page"
    verifyText "xpath://h1[class='mainHeader']" "Home Page"
    verifyText "id=loginLink" "Login"

Flow: User clicks login link
    click "id=loginLink"
    waitForPageToLoad 5000

Expectation: User sees a login form requesting credentials
    verifyElementPresent "id=usernameLogin"
    verifyElementPresent "id=passwordLogin"
    verifyElementPresent "xpath://input[@class='loginButton']"

Flow: User enters credentials and submits form
    type "id=usernameLogin" "myusername"
    type "id=passwordLogin" "mypassword"
    click "xpath://input[@class='loginButton']"
    waitForPageToLoad 5000

Expectation: User sees a landing page with a list of submitted articles
    verifyTitle "Welcome Michael!"
    verifyElementPresent "xpath://div[@class='article']"

Make sense? The Selenese code above in a text file in effect becomes the fixture code for our executable use case. Executing Spectacular would look like (assuming we named the Selenese file “login.selenese” and the spec as “SystemSpec.html”):

> Spectacular -fixtures ./login.selenese -specLocation ./SystemSpec.html
 -seleniumRCHost localhost -seleniumRCPort 4444
-seleniumRCInitialUrl http://system-uat/ -seleniumRCStartCommand *safari

(don’t worry, these commands can be stored in a project xml file so that running Spectacular doesn’t require such a long command line )

By default, results are output in the current directory as “TestResults.html”, which will be the same document the team wrote, but with annotated test results in the use case table. In our case, we haven’t written any implementation code yet, so it would look like this:

This is the essence of writing Executable Use Cases with Spectacular. For more details about how to write them or how to write the fixtures using other methods, visit the Spectacular EUC documentation.

Next in the “Using Spectacular” series, I’ll focus on how to document the executable use cases along with FIT and Gherkin/BDD tests and what they look like…

Boy, have I been busy the past couple months! And now, I’m comfortable enough to announce what I’ve been working on – my first major open-source project:

Spectacular: An Acceptance Test Driven Development tool for teams who like and/or must write official specs and who do not want to be constrained to a single ATDD tool.

Spectacular is an Acceptance Test Driven Development (ATDD) / Behavior Driven Development (BDD) tool that aggregates several different types of testing frameworks into 1, and it also introduces the idea of Executable Use Cases (EUC) – if you have to write use cases, you might as well make them Not Suck.

The idea is that a Business Analyst (BA), Quality Assurance engineer (QA), or Developer can write a spec in any way they feel comfortable with, including diagrams and business rules if necessary. They can write tests in the form of Executable Use Cases, BDD-style tests (Gherkin/Given-When-Then scenarios), and/or FIT-style tests all within the same document. The tool will run through the document, “detect” test cases, execute them, and print out the results in the same format as it was input.

Why build Spectacular?

I work at a large financial services company, where compliance with Sarbanes-Oxley (SOX) and Office of the Comptroller of the Currency (OCC) rules and regulations is of utmost importance, specifically with the audit requirements.

I suspect that there are many, many organizations out there who have to comply with the same set of rules, so I took what I learned about SOX and OCC audit requirements, combined them with what I learned at Elisabeth Hendrickson’s AMAZING ATDD course, and created Spectacular to make writing requirements more natural while also making those same documents executable, and not restricting any team to any single tool.

Also, I found through practical application of various ATDD tools that they are all pretty amazing and useful, but it was really annoying to use all these various tools to write specs and tests in different ways located in different locations depending on the tool being used. Plus, I would suspect that most teams would prefer to write story tests in a single document in a single format rather than having them live all over the place.

Isn’t this whole idea… un-Agile?

I don’t think so. Actually, I think something like Spectacular will help any large organization with an established corporate hierarchy and previous experience writing specifications in a use-case format adopt Agile more easily, especially those with “hardened” quality-assurance/quality-control groups. In my experience, these large organizations can be like “steering the Titanic with a small rudder” when it comes to transitioning to a more Agile process – allowing teams to continue writing requirements in the form of Use Case flows and documenting the tests in the same document will let them experiment with the various ATDD best-practices while remaining compliant with their regulatory bodies.

Spectacular helps those teams constrained with writing full-specs by allowing those teams to write the specs with tests embedded in them. Agility is introduced because those specs – written in a format they are used to – are now executable. A core Agile practice IMHO.

Use Cases? Really?

Yes, really. Use cases can tell a lot of the “story” if written well. Use cases, just like implementation code when written after a unit test is written, can be written well if there a constraint of execution behind it. Also, traditionally use cases have been taken to a far extreme of complicated. Not necessary IMHO.

To me, Use Cases fill the role of “Epic Spec” in an agile process. I’m a huge believer in the practice of Story Mapping and Persona Development (from Jeff Patton and Dave Hussman, respectively. Two of my personal geek-heroes). While doing your story mapping workshop, the high-level “activities” that you decompose into stories can very easily be Use Cases. In fact, in my experience writing Use Cases to explain the high-level activity (or “Epic”) can help to decompose it into discreet stories. And as such, each level of requirement-granularity (from Epic/Use Case to the Story) requires a different way to test it.

As such, I use Spectacular myself to execute Use Cases against Epics, and BDD/Gherkin and FIT tests to execute Stories.

Enough already. I get it. Show me how it works…

I don’t know about the rest of you, but I hate it when I stumble upon a useful open-source tool only to find that the documentation is poorly written. Now, I’m not saying Spectacular’s docs are amazing, but I did spend some time writing a good amount to make sure people could pick up Spectacular and use it relatively quickly. All of the docs are located at the Spectacular Wiki on Google Code. I welcome all feedback so that the documentation can be improved!

But here’s an example. Given a document:

Activity: Registration

(Executable Use Case)

Business Rules:

• Username must not exist in system already
• Email must not exist in system already
• User must be 18 years or older
• User must supply a username, email address (well formed), birth date, password.
• User must confirm password before proceeding

Story: As a new user not already registered I want to register myself so that I can use the system.

(BDD/Gherkin Executable Test)

Story: As a new user not already registered I should not be able to skip any data elements so that…

(FIT executable test)

With these requirements written, Spectacular will run through this document and parse out the tests (basically, anything contained in a table and fitting particular patterns) and execute test fixtures for each of these. While for version 1.0 Spectacular only supports Java (using JBehave) for the BDD/Gherkin and FIT tests, Executable Use Case fixtures can be written in Java, Groovy, Ruby (experimental – using JRuby), and Selenese (to directly drive a browser using SeleniumRC). The ability to write fixtures for BDD/Gherkin and FIT in other languages is coming soon! (I’d really like to be able to write BDD/Gherkin tests using Cucumber as the engine if possible)

• How to write a fixture for Executable Use Cases
• How to write a BDD/Gherkin fixture
• How to write a FIT fixture

In Conclusion…

Try it out! I hope the Agile community finds some use out of this tool like I have. If you have any questions, you can leave them here in comments or join the users & dev lists.

Attribution

Much of Spectacular is based in part or whole from the following projects:

• JBehave
• FIT
• Cucumber

As well as from the teaching/writing/works from the following people:

• Alistair Cockburn (Use Case guru)
• Aslak Hellesoy (original author of Cucumber)
• Elisabeth Hendrickson (amazing ATDD instructor and mentor)
• Dan North (the BDD guy at ThoughtWorks)
• Liz Keogh (the JBehave gal at ThoughtWorks)
• Dave Hussman (agile Persona development)
• Jeff Patton (Story Mapping)

I’m having a total brainfart on using commons-CLI and PosixParser. For some reason, the following test is failing:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

 
    @Test
    public void testSpikeOnPosixParser() throws Exception {
 
        Options options = new Options();
        options.addOption("m", "multichar", true, "some description");
 
        CommandLineParser cmdLineParser = new PosixParser();
        CommandLine cmdLine = cmdLineParser.parse(options, new String[] {"-multichar", "somevalue"});
 
        assertNotNull(cmdLine);
        assertTrue(cmdLine.hasOption("multichar"));
        assertEquals("somevalue", cmdLine.getOptionValue("multichar"));
 
 
    }

The test fails at the assertTrue statement on line 12.

Why? Am I misunderstanding the JavaDocs? Or am I being a dunce and forgot how to use commons-cli?

Arg.

I haven’t updated my blog in a while…  sorry for that.  Besides my day job, I’ve been busily working on a new open-source project that has been in my head for quite a while now and I finally decided to just go for it.  I’m almost close to “announcing” it more publicly, but for right now I am gathering some feedback from colleagues before I unleash my horrifying code for the world to consume.

More later…

I think Agile has a problem – it needs to grow up a little bit.

I’m not talking about “growing up” in terms of being more adopted.  I think Agile (and it’s various incarnations/methodologies) has far reached the point where it is considered mainstream.  At least to the point where it can be considered a viable option for teams/companies along with RUP and the likes.

What I mean by “growing up” is a change from rather informal, lax naming conventions that are, well, kinda puerile (“ScrumMaster?”) and tend to raise eyebrows a bit to folks in the corporate hierarchy, which tends to make them take Agile less serious because it seems like the Agile terminology was thought-up by a bunch of 16-year-old S&M RPG gamers.

I work for a well-known, established gargantuan of a company.  The senior managers tend to be a bit more conservative than, say, the folks (wonderful as they are) at Twitter, Inc., Facebook, Inc., or <enter startup created by 25 year old geniuses here>, Inc.  When I bring up Agile techniques to my senior managers, or do some coaching for teams new to implementing Agile, I always find a few people don’t take what I am trying to coach seriously at first, which makes my job just a tad bit harder.  And that’s just the “do-ers” on the teams – for senior managers, I can see their little snarky grins when I talk about the role of “Scrum Masters” or techniques such as Kanban.  Which actually makes it a LOT harder to push Agile as a strategy, especially when those same senior managers are the ones who have to sign off on said strategy.

The best (worst?) meeting ever came after a coaching session with a technical team, and I brought up the XP technique of “promiscuous pairing.”  The dev manager pulled me aside and asked me (paraphrase) if some of these Agile “things” came out of swinger communities.  (note:  link not safe for work – see what I mean?)

I have found that once I changed the terminology of certain Agile techniques or roles folks took the philosophy quite a bit more seriously.  Examples of terminology adaptations include:

• ScrumMaster -> Facilitator or Iteration Manager
• Sprint -> Iteration
• Backlog -> Prioritized Requirements
• Kanban -> Taskboard
• “Planning Game” -> Sizing/Estimation Workshop
• “Promiscuous Pairing” -> On-demand peer review

The list goes on…  The problem with the adaptations is that they are not official Agile terms, and so folks doing research on their own tend to not find the right kind of information because the Agile community uses the more informal terms.

I do get it – I understand why we use the more informal terms.  Agile is a new way of thinking for a lot of development teams (though, I argue that it is a cleaner, more refined regurgitation of the old RAD style, but I digress), and with the new way of thinking we should use new terminology so that folks think about how they approach activities differently (i.e. if you call it a “requirement” they will do the old-style deep up-front analysis whereas “User Story” won’t invoke such a trained reaction).  But as Agile adoption becomes more mature and enters the more mainstream “boring” old companies, I think we as a community need to take stock and consider formalizing the techniques and giving them names my senior managers won’t giggle at.

To be fair, some of the Agile terms aren’t that bad;  things such as “Sprint” can be easily translated to “Iteration” without much problem and doesn’t raise many eyebrows.  But, “ScrumMaster?”  Are you kidding me?  Oh, and “Backlog.”  Now, this is something I didn’t realize until I started at my current employer, but “Backlog” has a bit of a negative connotation with many old-school senior managers, as it used to mean a list of things that are behind or late and needed to be done.  In Agile, it means a prioritized list of things that need to be done as well, but “backlog” also implies those items are late and it’s bad.  I’m not saying that’s right, it just is what it is.  In fact, in sales organizations a backlog generally infers a list of customer orders/requests not yet fulfilled, but is also generally described in monetary units and not as individual items.  Another confusion.

The “planning game” is simply silly.  Many folks involved in software development do not consider planning, sizing, and estimating a game at all.  It’s “serious business” and many careers are staked in proper planning.

Again, I do realize many of these terms are meant to be taken lightly – and part of doing Agile is inserting “fun” back into software development.  But we also have to remember that not everyone thinks of software development as “fun” and that your manager may be more of an MBA-type rather than a Computer Science-type.

So I ask – is it time for us to consider making some of our techniques and methodologies a little more formal and a little less….  childish?

Just a thought.

So, I read someone’s blog post about the pros and cons of using UUIDs as primary keys.  I am a big believer in using UUIDs as primary keys for domain objects in the DB.  Having used them quite a bit in my projects, I wanted to debate a couple of the cons listed in the original post.

1.  Performance can be an issue:  Yes, it can, but grabbing a sequence from the DB creates a bigger issue (2 calls per new insert, depending on the RDBMS platform).  This can be easily remedied by writing a simple UUID pool object which generates the UUIDs in batch, and doles them out on request.  When the pool runs low/out, regenerate.

2.  Ordering/Sorting.  Indeed, you really cannot order by the primary key in the case of a UUID.  But then again, why does one usually order by primary key?  Sequential primary keys tend to indicate the order of entity creation.  Good DB design principles include having a created_date and a modify_date column as part of the entity (depending on your needs and requirements, of course, but I’d say this is mostly true).  With this in mind, you CAN order by the create date.

3.  cannot test if a record has already been persisted by checking if the Id field has been set.  Uhm, you can write a @GenericGenerator to generate the uuid if you’re using a JPA provider other than hibernate, and it wouldn’t be hard at all.  The UUID is only set upon insert call to the DB, so you can do this check.  But the OP is right, I question a design that checks for the existence of a PK being set.

Now, not all is roses of course.  Using the pre-generated strategy in point #1 means that once in a while you may be generating 100 UUIDs to populate the pool, creating a slight response lag for that 1 in 100 new inserts (if you have a 100 UUID pool for example).  This is akin to a GC cleanup cycle, though less harsh I think.

Depending on the DB platform, sorting by date columns can be slower, though I argue not so slow as to affect performance significantly.

One thing that annoys operations folks who may be tracking a transaction of some kind through multiple systems, with each transaction entity (whatever that is for your case) being marked with a UUID.  So, rather than using a simple number as a tracking tag, you’re using a somewhat-hard-to-read 32 character (or more with hyphens) string.

Other than that, I think UUIDs are (generally) the best way to go with PKs.  Personally, I make it a general rule to treat PKs as an implementation issue with using RDBMs and not an actual part of the persisted domain entity.

It is amazing.  I am on an airplane, blogging.  I have actual internet access.  At a speed that is quite respectable.  Fabulous is the word that comes to mind, though it doesn’t quite fully capture just how amazing this feature really is.

I am not sure I can ever fly another airline after this.  Well, I hear Delta has a similar service, not sure if it’s available across their entire fleet.

So, on a related note, it seems that even Virgin America First Class cannot be rid of those complete douchebags you seem to run across on a flight.  You know the type – the really cranky asshole who is SO COMPLETELY INCONVENIENCED by something that happened to him earlier in the morning, and has to take it out on his fellow passengers or, worse yet, the flight attendants.  Lately I have been traveling a lot for work and so my tolerance level for airport craziness has gotten a lot better, as it is clear that people who work in the airports have a very, very tough job.  Yes, I know it looks like they are somehow incompetent or don’t really care about you.  Maybe that’s true for some of them.  But give these folks a break – they also have to deal with security, the stringent rules placed upon them (and by extension, the rest of us) by the FAA, etc.

Anyhow – today’s douchebag was a first class passenger, who decided to completely ignore the rules regarding how much luggage to bring on the plane.  As he stepped on board, he took his carryon rollerbag and placed it in the overhead bin above the seat across the aisle from him.  Not above HIS seat, the OTHER seat.  Note, he could have spent abotu 30 seconds making room for his bag by doing a little shifting, but clearly that was too much work for him.

As he was doing this, the guy behind him asked if he could move his bag to his side so he can place his bag above his seat.  You see, the other guy’s seat was right below the bin where the douchebag placed his rollaround bag.  The douchebag’s response?  “WELCOME TO LIFE BUDDY TOO FUCKING BAD.”

I kid you not.  WHAT?  Are you serious?  Are you really that much of a dick, you have to treat your fellow human who has to sit across the aisle from you like that?  OMG.

The flight attendant did her best to make everyone happy, and really, she was amazing.  She ended up doing the shifting on behalf of Mr. Douchebag.

Seriously people – you really need to check your attitude at the gate (literally) when you get on an airplane.  No one really wants to be on it.  Well okay, not really true.  I could live in my first-class wifi-enabled seat, eating my fresh fruit, yogurt, and hot cinnamon roll while blogging.    But still…

Outside of that moment, this is the most amazing flight I have ever been on.  Thank you Virgin!

There has been a lot of chatter recently about the value of [enter Agile methodology here] certification. I think a lot of the chatter is due to the controversy surrounding the Scrum Alliance’s letters to various user groups, asking them to “license” the Scrum name. And I believe the other reason is the huge number of trainers out there making quite a living doing the Scrum certification thing.

Part of that last sentence isn’t fair. People need to make livings. And, there is immense – if not, with the right people, priceless – value in those who have led teams down the Agile path teaching and coaching others to do the same. But as with anything that looks really cool and works, you have folks who go through the certification motions just for the sole purpose of being able to make good money. It’s those who don’t see their career as a craft or who have real passion in what they do – they just want more money. Not that capitalism and the desire to be wealthy is bad, no judgments there. But I get the feeling that many of the “Agile trainers” out there just aren’t of the quality that many teams need. To extend the idea in my last entry (“architects who don’t code are like fashion designers who don’t sew”), there are a lot of people out in the field training novices how to design clothes without ever having picked up a sewing needle. Certified trainers, no less. I know, I’ve run into a few.

I really like Elisabeth Hendrickson’s take on certification, and the alternatives to official certification: WeVouchFor.

And, like Elisabeth, I must confess – I got started in Agile by going to Ken Schwaber’s CSM class in 2004. At the time I did not think much of the whole issue with certification. But now? Well, I’ve simply met too many Agilists who still just don’t get it.

And I’m not going to sit here writing in my holier-than-thou blog trying to convince myself that I know everything and I totally get everything. At least, I hope that’s not what I’m trying to do. I hope the day where I stop learning never comes. But, I can say that I have some good experience, both on a small-company level and at a large-company level, in rolling out and/or practicing Agile techniques. And by experience, I mean, I have been blessed with the ability to totally and royally fuck up beyond belief, get my ass burned by my various managers/clients, and learn from it and move forward.

My point? How can we “certify” experience? In Agile (and I would assume in RUP, Waterfall, etc other process), experience counts for so much more than simply education. Agile techniques at their basic level are taught, but they are further refined at the company, team, and individual level through tweaks after doing. A.K.A. screwing up, learning-through-retrospective, moving on. How in the world do we certify that? The closest thing I can think of is something along the lines of WeVouchFor. I like that I am  able to describe my own skills (i.e., “Coached teams”) and have people specifically vouch for that piece (“Michael coached me”) and provide evidence/testimony to it (“result was a team practicing Agile and still is!”).

Of course, I see a small danger here too.  I see a danger of “you scratch my back, I’ll scratch yours.”  Again, it’s not a bad thing if the scratching really happened.  But “official certification” does offer potential employers and clients some sense of understanding that the certified person did, in fact, attend a class and did, in fact, pass it.  Vouching does not.

I don’t have an answer.  I have some ideas.  I need to think about them some more.  I like the idea of possibly letting certain “vouches” carry more weight than others, and that reciprocal vouches are worth the least.  Again, the logic still has problems. How would you quantify the value?  Points?

This particular topic was the one thing I wanted to bring up during the AgilePalooza Open Space, until I was rudely interrupted by my employer and had to leave.  Perhaps next time.

A great analogy, brought to you by a viewing of Bravo TV’s “The Fashion Show.”

Here it is:  An architect who does not code produces the same quality of work as a fashion designer who does not sew.

Please, for all of you who hold that title of “Architect:”  Do not tell me your “team of people” will dive into the details.  If you do not know the ramifications of your design (which eventually come out in the details) then show me someone who does.  If you’re responsible for systems design, even at bird’s eye level, please be able to do some coding so prove your design, even if you’re not officially coding for the project.

Seriously.

Read on Bob Lee’s blog about a new collaborative effort to “standardize” dependency injection via annotations:

@javax.inject.Inject at Google Code

Neat!  I’m very happy to see this came about as a collaboration between the 2 competitors.  I use that word a bit loosely here of course, as I switch between using Spring and Guice depending on the project and its needs, and (to me) they serve different types of applications.

Congrats guys!

From MacRumors:  Apple’s Cash Hoard Triggers Acqusition Rumors

So, this scares me just a little bit.  It was not that long ago when Apple was bleeding – nay, hemmoraging – money from every pore.  It had piled up wads of money in previous years which pretty much kept it alive  long enough to buy back Steve Jobs and rescue the company from its failed product strategy.

I’m hoping the rumors are just that – rumors.  IMHO Apple, while making amazing products and therefore making amazing money right now, could just as easily fall out of favor with finicky consumers and find itself in an all-t00-familiar position all over again.  It will need that hoard of cash to reformulate and adapt, just like it did before.

I’m all for dividend distribution in general as well, but not for companies like Apple.  Or Microsoft, for that matter.  These companies are not in a business that is constant or stable – technology is still ever-adapting and ever-competitive, and realignments are common.  That takes cash.

Besides, WTF would Apple do with Twitter anyway?  Honestly, I’m still at a loss for what Twitter is exactly for, anyway.  Marketers tell me it’s an amazing channel, but people don’t go to Twitter so they can be marketed to, they go there to communicate.  Just like on Facebook.  Just like they did on MySpace.  MySpace fell out of favor, as will Facebook, and will Twitter.  I would say Twitter is well on its way, now that “tweeting” is a mass-market phenomenon and no longer a tool of the hipsters only.  That’s usually when these things start to become boring.

Electronic Arts?  That kinda makes sense.  MacOS has always had a big gap in its games category.  Most popular games are developed for the Windows platform (though recently EA has committed to developing for the Mac, and of course World of Warcraft (Warcrack?) is on the Mac, thankfully).  But I think that gap can be filled without spending the savings account.

My $0.02 on the matter, FWIW.

Here I thought I was going to have to bite the bullet and learn more than a little bit of Ruby by way of Behavior Driven Development.  I thought I was going to have to actually put my head down and start active coding in Ruby in order to use the Cucumber BDD framework, specifically to parse the Given/When/Then clauses.

I thought about writing my own framework to do just that in Java, and actually started to.  Then I went to the magical Google and – wouldn’t you know it? – I found JBehave.  Of course!  I knew Dan wouldn’t have let me down by making me go the way of Ruby   (not that there’s anything wrong with Ruby, I just like to take my sweet time drinking kool-aid )

I love how it is just as easy to write JBehave tests as it is to write Cucumber tests:

Given a user with the email address “someone@something.com” has not already registered with the system
When a user tries to register in the system with the email of “someone@something.com”
And a name of “Michael Dowling”
And a date of birth of “1/1/1985″ (yeah right)
Then register the user with an access token of “Registered”

In JBehave, being clearly well-designed in an IoC manner, asks you write the Steps to execute the above spec:

package minderupt.scenarios.steps;
 
import org.jbehave.scenario.annotations.Given;
import org.jbehave.scenario.annotations.Then;
import org.jbehave.scenario.annotations.When;
import org.jbehave.scenario.steps.Steps;
 
public class CreateUserSteps extends Steps {
 
	private String email;
 
	@Given("a user with the email address \"$email\" has not already registered with the system")
	public void checkForRegisteredUser(String email) {
		// code to check for pre-existing email
	}
 
	@When("a user tries to register in the system with the email of \"$email\"")
	public void registerUserWithEmail(String email) {
		// code to register with email
	}
 
	@When("a name of \"$name\"")
	public void registerUserWithFullName(String name) {
		// code to register with name
	}
 
	@When("a date of birth of \"$dob\"")
	public void registerUserWithDateOfBirth(String dob) {
		// code to register with DOB
	}
 
	@Then("register the user with an access token of \"$token\"")
	public void checkForCreatedUser(String tokenExpected) {
		// register user and confirm returned token, blah blah
	}
 
}

…and then write the actual test case, specifying configuration options and the actual steps to execute during the test:

package minderupt.scenarios;
 
import org.jbehave.scenario.JUnitScenario;
import org.jbehave.scenario.Scenario;
 
import minderupt.scenarios.steps.CreateUserSteps;
 
public class CreateUser extends Scenario {
 
	public CreateUser() {
		super(new CreateUserSteps());
	}
 
}

I like this approach for multiple reasons, not the least because I can re-use the steps for different spec documents utilizing the same language, but also, I can change the test case configuration so that on my dev machine (local build) I can run all the tests and simply outputthe results to my console, but in my CI system, the output goes out to some kind of standard reporting system in pretty HTML.  Yay.

Like I mentioned in a previous post, one of the things I want to do is be able to fully spec out a requirement in a document (in Word, HTML, Wiki, etc) which will have a mix of business logic rules, FIT tests, and BDD tests.  Then as part of a build, split out the FIT tests and run FIT against those, parse out the BDD tests and run those, and then output a report back into the combined document for the entire team to see.  Can’t be too hard, just a matter of parsing Word/HTML, recognizing the type of tests, and running them.  Integration project, really.

But I think it would be immensely useful, especially for organizations that (still) communicate over such types of documentation;  a behavior that I feel isn’t going away anytime soon.  Might as well make the transition a little bit easier, I think.

Believe it or not, I ask this question all the time.

I come from the belief that if you’re in a team, and you’re getting products out the door, and your product owners/managers are happy, and your developers are happy, and (most importantly) your customers are happy, then why adopt Agile?

As I am an Agile enthusiast, you’re probably shocked to read the above paragraph.  But, why?  See – I like asking this question because it lets me really understand why a team wants Agile coaching.  Sometimes I get a team that wants to  implement Agile, but not because they want to improve themselves but rather because their manager told them to do it.  I’ve learned through the years that those teams who are forced to do Agile without having internal reasons for doing so, tend to fail at implementing Agile.  Or they end up worse off than they were before.

In order to implement Agile the team has to commit to some minimum disciplines in order to be successful.  Scrum is a great overall process but for software engineering jobs it must also be supplemented with development practices (unit testing, automated acceptance testing, modular codebase, etc).  The testing team also has to be on board with a dramatic change.  These things cannot just be “adopted” willy-nilly – it takes commitment.  And teams without that level of commitment – to themselves, to quality, to their customers – should just not bother.

Of course, these practices don’t have to be adopted all at once – it is expected to happen piece-by-piece as well.  But the commitment must be there to eventually get to that point.

A couple weeks ago I attended a public class led by Elisabeth Hendrickson and Dale Emery (which, btw, was aboslutely AMAZING and if you have not taken their class before, I would highly recommend that you do so).  Two things stood out during that 3-day class:  Elisabeth’s simulation (where we all naturally migrated to a more test-first process), and the discussion around ATDD using natural domain language.

For example:

Given a user with the email address “someone@something.com” has not already registered with the system

When a user tries to register in the system with the email of “someone@something.com”

And a name of “Michael Dowling”

And a date of birth of “1/1/1985″ (yeah right)

Then register the user with an access token of “Registered”

This executes the following Cucumber code (in Ruby):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

Given /a user with the email address "(.*?)" has not already registered with the system/ do |email|
  @email = email
end
 
When /a user tries to register in the system with the email of "(.*?)"/ do |registerEmail|
  @registerEmail = registerEmail
end
 
When /a name of "(.*?)"/ do |name|
  @registerName = name
end
 
When /a date of birth of "(.*?)\/(.*?)\/(.*?)"/ do |dobMonth, dobDay, dobYear|
  @month = dobMonth
  @day = dobDay
  @year = dobYear
end
 
Then /register the user with an access token of "Registered"/ do
  token = RegistrationService.register @registerEmail @registerName @month @day @year
  if token != "Registered"
    raise "Not registered"
end

The neat part of this is that it is an executable document;  meaning, it is input to “test fixtures” written by development to test the software being developed from an acceptance point-of-view.  This is the essence of “Behavior Driven Development” or BDD, of which I am a total convert.

I want to write much more about this topic – and I will.  For now, though, the one though swirling through my head is the need to have documents be in formats large organizations (such as my employer) use to describe requirements (behaviors).  I doubt it will be possible for most teams to check-in plain text files and be comfortable with that.  Plus, these documents will need to be passed around, possibly stored in Wikis, or other document management systems (even though ideally, these documents would be in source control along with the ATDD code).

I think I found a new project for myself.  Hmmm….

From InfoQ:  Scrum Alliance Asks User Group to Sign Licensing Agreement

Yikes.  Upon first reading the headline of this article all I could think was “oh crap, this marks the beginning of the end for Scrum.“  At this point, the Lean zealots are throwing their hands in the air exclaiming “I told you so!“  Ha, perhaps.

What I like about Scrum is the overall process components it gives us.  It tells us to use a backlog, but it doesn’t tell us what those backlog items must be.  It is common to use User Stories as backlog items, but I’ve worked with teams who use bug reports as backlog items.  Scrum gives us the concept of the “Planning Meeting” where we estimate the backlog items and commit to work during the Sprint, but there is no defined agenda for the meeting.  It is common to use XP’s model for planning (“The Planning Game“), among others.  Same with the demo, the retrospective, and the sprint itself.  Heck, even the sprint length is negotiable!

The point is, we get carried away with the notion of “pure Scrum.”  I find the whole certification practice around Scrum to be completely ridiculous, as groups rarely implement “pure Scrum” because it doesn’t exist.  The components within Scrum tend to be customized by the team, especially during the retrospective.  And it is even more common to use Lean techniques for doing so (which is why I find the fight between Alan Shalloway and his group of Lean folks and Ken Schwaber and his Scrum folks to be equally stupid as Agile certification programs), making Lean and Scrum obvious cooperative processes.

Also, need I remind the Scrum folks that the word originates from a Rugby move?

I will still practice Scrum for the foreseeable future, as I’ve seen so many amazing improvements to teams that I have implemented Agile with.  In each of these teams I hold the expectation that the basic process of Scrum will be modified to fit the needs of the team, which is exactly what I tell them. Besides, some of the most common question I get when I coach teams in Agile is “what about testing?”  “What about development?”  Again, other Agile practices being brought into the Scrum team negate the whole idea of “pure Scrum” and therefore no one organization can own the process.

I’d like to see them try.

I’ve always been a huge believer in using Code Coverage tools (such as Clover, CodeCover, EMMA, gcov, etc) as a way to report on how in-depth your unit tests are.  Generally, I use them with Quality Assurance/Quality Control groups to determine where to focus any additional testing efforts during a Sprint.  While we tend to benchmark required coverage at 85%, this is always a general rule with the understanding that every project (and, therefore, every project’s code) is going to be different, with different needs.

An interesting post at InfoQ talks a bit about the need to be careful about using a required coverage metric during TDD:

Out of the gates, Gruber’s primary statement is that TDD proponents do not suggest code coverage as “a one true metric”, that it is useful but only to degree and taken in context with other sources of feedback. He denounces Pang’s claim that “(Pang) 100% code coverage has long been the ultimate goal of testing fanatics”, stating that “(Gruber) high code coverage is a desired attribute of a well tested system, but the goal is to have a fully and sufficiently tested system”.

I completely agree with this statement.  Code coverage is, again, a tool for determining where additional testing time can be spent, as well as identifying any risks of releasing code into production that is not currently covered by unit tests.

The following quote sums it up nicely:

code coverage [in the context of TDD] is a great way to notice that you screwed up and missed something, but nothing else

More information can be found on InfoQ’s post.