Tuesday, October 25, 2011

When the Cucumber is mightier than the Pen - Fixing Rails 3 in Action

Aslak Hellesoy and the good people behind Cucumber have realized there was a problem in the Cucumber community. People were using web_steps to build, rather than just as a set of examples. So, the latest versions of cucumber have removed the creation of web_steps and the attendant files when you run the generator.

As Mr. Hellesoy noted in his blog entry, this is going to break a lot of Rails training materials which have come to rely on these files being available.

Having recently gotten a copy of Rails 3 in Action and noticing that an edit seems to be a ways off, I offer my humble solution for getting through chapter 3 of this book using the latest Cucumber. You can and probably should still read through the text that I skip in the book, as it does give you insights, but my path below will allow you to use Cucumber the 'right' way.


The trouble starts on Page 55

I have rewritten the Gherkin for the feature file. Notice the more domain language syntax?

Listing 3.8 
Feature: Create projects
In order to have projects to assign tickets to
As a user
I want to create them easily 
Scenario: Creating a project
Given I am on the homepage
When I navigate to the new project creation page
And I create a new project
Then I should be shown the project created verification message

Then skip to the portion about doing the db migration

rake db:migrate (page 56)
rake cucumber:ok

You can implement step definitions for undefined steps with these snippets:

Given /^I am on the homepage$/ do
  pending # express the regexp above with the code you wish you had
end
When /^I navigate to the new project creation page$/ do
  pending # express the regexp above with the code you wish you had
end
When /^I create a new project$/ do
  pending # express the regexp above with the code you wish you had
end
Then /^I should be shown the project created verification$/ do
  pending # express the regexp above with the code you wish you had
end


stick this in features/step_definitions/project_steps.rb


Given /^I am on the homepage$/ do
  visit('/')
end
When /^I navigate to the new project creation page$/ do
  click_link('New Project')
end
When /^I create a new project$/ do
  fill_in('Name', :with => 'TextMate 2')
  click_button('Create Project')
end
Then /^I should be shown the project created verification$/ do
  page.should have_content("Project has been created.")
end


The visit('/') is substituted for the path_to stuff from web_steps that is mentioned on page 56

basically we are sending it to the root 

continue to page 57-58

when editing the routes.rb file


  # You can have the root of your site routed with "root"
  # just remember to delete public/index.html.
  # root :to => 'welcome#index'
  root :to => "projects#index"
...

continue through to page 61

when editing routes.rb


  # Sample resource route (maps HTTP verbs to controller actions automatically):
  #   resources :products
  resources :projects
You can continue on till Page 73 adding a title:

add the following line to the creating_projects.feature

And I should be on the project page for the new project

running rake cucumber:ok will give you the following step def to add to your file (project_steps.rb)

Then /^I should be on the project page for the new project$/ do
  pending # express the regexp above with the code you wish you had
end 
Then edit this to:
Then /^I should be on the project page for the new project$/ do
  current_path.should == project_path(Project.find_by_name!('TextMate 2'))
  page.should have_content("TextMate 2 - Projects - Ticketee")
end

This replaces the paths.rb stuff and the other web_steps.rb stuff referred to on page 73

do read the stuff on the bottom of page 73-74 about the dynamic method invocation

rake cucumber:ok

will give following error:


"expected there to be content "TextMate 2 - Projects - Ticketee" in "Ticketee\n\n  \n    Project has been created.\n  \nTextMate 2\n\n\n" (RSpec::Expectations::ExpectationNotMetError)"
(instead of the expected #has_content? error mentioned in the text)

both are Rspec type errors though

continue on with page 74-77

New Cucumber Feature for Page 77

make your features/creating_projects.feature look like:

Feature: Creating projects
  In order to have projects to assign tickets to
  As a user
  I want to create them easily 
  Background:
     Given I am on the homepage
     When I navigate to the new project creation page

  Scenario: Creating a project 
    And I create a new project                           
    Then I should be shown the project created verification
    And I should be on the project page for the new project 
  Scenario: Creating a project without a name
     And I try to create a project without a name
     Then I should be informed that the project has not been created
     And I should be told that the name is required

rake cucumber:ok

Add these to the project_steps.rb

When /^I try to create a project without a name$/ do
  pending # express the regexp above with the code you wish you had
end
Then /^I should be informed that the project has not been created$/ do
  pending # express the regexp above with the code you wish you had
end
Then /^I should be told that the name is required\.$/ do
  pending # express the regexp above with the code you wish you had
end

Implement them as per below:

When /^I try to create a project without a name$/ do
  click_button('Create Project')
end
Then /^I should be informed that the project has not been created$/ do
  page.should have_content("Project has not been created.")
end
Then /^I should be told that the name is required\.$/ do
  page.should have_content("Name can't be blank")
end

This should get you on track to continue at the bottom of page 77.


I realize my Tests are not ideal. For instance the second scenario could also check that on a failed verification you stay on the New Project page. I was simply trying to mirror what the book had and put it into a more business domain syntax. It also nicely shows the division between the Gherkin and the step definitions.

Hopefully this is helpful to others. As I have time to go through the book, I will try to add further updates, but this should give most a good start in the right direction.

I am eager to see other modifications others make to this.

Eat your meat AND your vegetables!

No matter what dietary fads are upon us, most of us realize that we need to eat a balanced diet.*

Why is it in the software industry that I so often see teams binging on just one thing when it comes to testing?

What I mean specifically, is testing frameworks. In the Rails world the frameworks du jour are RSpec, Cucumber and Steak - with a little Capybara sauce. Mmmm sounds tasty!

RSpec has become a solid core for all layers of testing with the other parts. Cucumber was initially created to make the BDD'ness more domain specific... so that customers/project owners/BA's could read and even write them. Unfortunately, many Gherkin examples in the wild tend to be anything but non-coder friendly. This seems to have occurred due to many factors which may come to play on a team. 

One of these factors seems to be part of what has attracted many people to Ruby on Rails in the first place. You often hear Rails coders talking about how they love it that RoR 'gets out of the way' and 'just lets them code'. This is definitely laudable when what is getting in the way is technical scaffolding or other technical encumbrances. It is like using a power tool over the old manual ones. Where it becomes a problem is when what is being 'gotten out of the way' is meaningful communication and collaboration across the team. Teams who have tried to get their 'business folks' involved through BDD have run into the problem that either the business loses interest or can't write the tests well enough. I believe at least a good portion of this is due to how the tests are being written. They are often too low level - basically a series of instructions for filling out web forms, clicking buttons, etc.  The folks behind Cucumber have tried to force a solution by removing one of the culprits they provided early on: web_steps.rb. Web_steps was a sample collection of step definitions around many boring day to day activities. Instead of serving simply as an example, teams baked their tests around it - creating many awful to read, low level test suites.

While I applaud the removal of web_steps on the part of Cucumber, it is having the oposite effect. Teams are just moving away from Cucumber to Steak (because it is more 'coder' friendly) for their Acceptance/Integration tests. What lies at the core is a one-two punch of badness that I am seeing more and more: Teams are confusing Integration Testing with Acceptance testing AND coders are writing those tests.

Acceptance tests should be written in the domain language of the business. They are meant to be high level - to provide the coders a place to start. 
Integration tests should be written to test across 'the stack' and as such are more focused on the implementation details. These are therefore in the more code like language of the implementation domain.
Unit Tests test the code directly... everyone knows the coders are supposed to write these. 

Cucumber is good for BDD acceptance tests. Steak is great for integration tests. Eat your meat and vegetables!

Let me suggest a possible test driven development team and their roles in testing under the above approach.

"The Business" (Story owners/Customers/BAs/etc) - write high level Acceptance Test Scenarios - These could even be part of the story. In essence they write the Cucumber Tests. (Someone else might actually cut and paste the tests into a 'feature' file, but you get the idea).

"Coders" (Software Engineers/Programmers/etc) - write the step definitions behind the Gherkin. Step definitions can be more implementation specific. Writing these can be the first time the coders actually start doing Test Driven Design. Then the coders write their Unit tests however they see fit.

"Testing Team" (Test Engineers/QAs) - write Integration tests using Steak, etc.

The above scenarios are based upon testing using Cucumber and Steak. It could just as well apply to the myriad other testing frameworks (Fitnesse, JBehave, Selenium, etc). The essence is that integration and acceptance testing should be separate endeavors.

I can hear the objections already.  

"We don't have a testing team.":  Fine, there are projects which are small enough, simple enough where the coders serve this role. The point is, integration testing is a different animal from acceptance testing.

"Our business people are not involved/would never write tests)": Really? Who writes your stories? Maybe they were driven away by previous bad cukes. Listen to your business people describe the functionality they want. "So I am on the home page and when I go to create a new account then I should get some indication that the account creation succeeded". That is practically Gherkin already! If they won't physically write the tests, then the BA's could certainly be following them around 'taking dictation' as the acceptance tests drip from the Owners' lips. 
On the other hand, if your business people are not involved, it is likely you have a deeper issue than what testing framework you are using. Do you have an Agility Coach?

"That is totally going to slow us down!": Again, fine! Speed by itself is not a good thing. Without direction it simply means you are going to drive off the cliff faster. If you are a business owner and the 'acceptance tests' you are being fed make you want to cry with their technical level of detail - ask why they are being written this way - or better yet - write them yourself. If the testing is being taken away from you completely, don't let them. Don't let anyone tell you that integration tests are the same thing as acceptance tests. Coders, if you want your business owners to engage more, realize that giving them pages of cryptic, coder centric tests to review does not really encourage their engagement. As stated before, the idea of BDD was to simplify acceptance gathering so that coders would know where to start. It supports Agility by giving a venue for business people and programers to collaborate frequently. In the end, the slight reduction in speed along a more prudently chosen path will likely save you way more time than a radical course change much later in the project.

All of this raises a number of other questions I have been pondering for years - such as having different types of 'Customers', What sufficiency of testing levels for a given project, optimizing testing approaches... 

It also makes me hungry...


* - my wife wanted me to note that our household is vegetarian and that I am only promoting Steak in the 'software' sense. Thank you dear! :-)

Friday, September 2, 2011

Shortcuts don't always get you where you set out for

I have lived in a lot of places over the years. I have learned with each new place to get out and drive (or better - bike or walk) to start to get a feel for the place. Assess the lay of the land if you will. A number of years ago I was enrolled in a three year program at St. Louis University. So, I got myself a map which I kept posted near the door to my then apartment. Every weekend I would pick a place or a route to explore. I would mark it on the map either upon my departure or return. One day I had decided to check out some places downtown. On my way out, I asked one of my friends who was a native if they could tell me the best way to get to the first building. I thanked him and started on my drive. About three-quarters of the way there, battling down-town traffic I caught a glimpse of the building I was trying to get to down a quiet side street. This is nuts I thought. Why am I dealing with all this traffic when the building is RIGHT there! Needless to say, I promptly turned down the almost empty side street and headed merrily towards my intended destination. I remember congratulating myself that I had found a faster way than my native friend and making plans to tell him about the route when I got back. Then I made it over the first hill. While I could clearly see the building I had set out for from the initial route, what I had not seen was that this street ended with a very solid structure between my car and the streets beyond which would actually take me there. Of course, it then took even longer to go back, re-merge with traffic and get to my final destination. It turns out that St. Louis has a lot of these deceitful "shortcuts". My friend had a good laugh when I got back. I realized that I had momentarily put the real goal at risk by prioritizing speed to the goal. In the end it took a lot longer.

Let me tell you another story. One of my passions for many years is the traditional martial art of fencing. After a while, I wound up teaching it myself and running a salle. Now, most people who start fencing have at best, romantic ideas about what they are getting into. Few have any other martial arts background when they come to the salle. Fewer still, if any, have trained their bodies in the way that is necessary to move in our art. Our job is to train them how not to be hit by someone intent on hitting them. One of the first lessons a student learns with sword in hand is their guards and their parries. Inevitably, their first parries are all really wide (a natural reaction when someone is coming at you with a sword!). We calmly explain that while they may have avoided that attack, what if it had been a feint? Their large motion has left them wide open in all the other lines of attack. We work with them over and over through drills to parry a precise way and precise distance. We also repeat over and over that the goal is not to be hit and that part of that is to be efficient enough to be able to deal with multiple changing attacks.

Now one of the unique parts of our salle is that we believe in having all levels train together. There is value for the novices to work with fencers who already have the basics down. Additionally, the advanced students never stop drilling the basics. Eventually, therefore, we will get the question: why do you make us parry that way when the more advanced fencers parry differently when they fence?
Of course when starting out, focusing on form is important because it is really teaching you something deeper: how to be efficient so as not to get hit. More advanced students know more ways to do this by manipulating time, distance, blade engagement, etc. A novice does not. But all the novice sees is that the advanced fencer is using a smaller parry or a larger parry than what they have been taught. The thing is, it takes a minimum of two years of training and constantly being told the mantras about not being hit, and fencing is about trained, logical, efficiency rather than reactive reflexes before it sinks in.

So what does all of this have to do with Agile Development?

A friend and fellow Agilist, Chris Bartling, tweeted about a post he saw the other day: http://t.co/jq531Il

The blogger, Jay Fields, makes an interesting point. The goal of paired programming seems to address this principle of the Agile Manifesto: "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." It also hits some of the other principles such as attention to technical excellence and of course the primary one of continually delivering valuable software (by quality checks and reduction of truck numbers). The thing is, no-where in the manifesto does it say that to achieve these goals you have to pair. Rather it trusts motivated, self reflective and self organizing teams to come up with good ways to meet these goals themselves. All of this I agree with. yet something still troubled me about the post.

Jay is like the native St. Louis resident, or the advanced fencer. He understands the deeper goals and has enough experience to be able to draw upon a myriad of techniques to achieve them. The thing is, it takes a minimum of two years of fencing training and constantly being told the mantras about not being hit, and fencing is about trained, logical, efficiency rather than reactive reflexes before it sinks in. Even after living years in a city, my knowledge of the most efficient routes will pale in comparison with someone who has spent their life there. Similarly, the principles of Agile development look great on paper... a team reads it and there is much head nodding and affirmative mumbling. Yet, they don't really sink in until you practice them. Jay mentions that he has been pairing for years before this recent project/position. Advanced fencers fence, novices practice techniques. Advanced Agilists are agile, teams new to Agility practice techniques to become more agile.

My concern with the post is that like so many novice fencers, teams new to Agility will just see Jay not doing a technique which they may not agree with or find particularly painful initially. They will ask, why should we do it if he isn't... can't we just ask each other questions when stuff comes up? Unfortunately, too often, new 'Agile' teams will fail to ask those questions. The rigor of stand-ups, TDD, pairing, even collocation, gets the team members into the habit of asking the right questions. It helps create a culture of communication and collaboration where it may not have existed before. Of course, simply doing these practices is not enough, and should never be dogmatically considered the 'only way to Agility' - a good coach will work with the team as individuals to nurture the new culture in subtle ways relevant to the team and individuals... but discarding a new practice without understanding the underlying goal or reason can wind up being as wasteful as my 'shortcut' in St. Louis - and probably a lot more costly.

Wednesday, April 20, 2011

Presenting on Agility in Second Life!

On Wed April 20th at 7pm PDT, I will be presenting in Second Life. The topic is "Developing Healthy Teams through Agility".

Second Life is a thriving Virtual Reality community on the internet. There is a group of Agilists who meet there regularly.

Follow this link to join us in Second Life for the presentation: http://maps.secondlife.com/secondlife/Agile%203D/60/123/25

Thursday, February 10, 2011

Prezi of a collaborative presentation on Virtue and Agility Patterns

I gave a dynamic, collaborative presentation on Virtue and Agility Patterns. Rather than using a slide based presentation, I used a tablet to mark up documents on the screen. This gave more of a feeling of using a whiteboard/chalkboard and allowed me to interact more with the audience.

Afterward, I compiled the artifacts into a Prezi.

All in all a neat experiment in making various presentation technologies work for us, rather than the other way around.

Sex, Lies & Agility Patterns on Prezi

Be sure to view it in full screen (under the More menu which appears at the bottom right corner of the Prezi).

Sunday, February 6, 2011

The Grammar of Agile Software Development

This is in response to David Hussman's Tweet : "+5 RT @jbrains: "Please please stop using 'agile' as a noun" - @pragdave (YES!!!!) #magicruby

Agile: (adjective)
Agilely: (adverb)
Agility: (noun)

Examples:

"We are striving to develop our software in a more agile manner." - (Agile describes the manner [noun: object of a preposition] in which they are trying to develop [verb] the software [direct object].)
"We are striving to develop our software more agilely" - (Agilely describes how they develop [verb])
"We seek greater agility in our software development" - (Agility is the object of their seeking - and is as such a noun/direct object)

I think that people have become lazy and started truncating the descriptive title "Agile Software Development" to just "Agile". I am as guilty of this as anyone. Unfortunately this has done more harm than good and has led to a lot of confusion. Particularly, it may have contributed to the misguided notion that Agility is a binary state - using "Agile" as a noun gives the impression that it either exists or does not exist ("Are you doing Agile?")whereas the term agility used in its common sense is well understood to be manifest in degrees.

"The young gymnast's agility was only enough to perform the most basic routine".
"All things which move of their own volition are agile, however they possess this agility to varying degrees. Hence a deer can move more agilely than a rhinoceros."

I hereafter shall endeavor to respect the proper terms of speech when discussing Agile Development.

Any other suggested corrections of the use of the term "Agile" and its variances?

Wednesday, January 26, 2011

Aristotelian Software Development = Agile Software Development?

I admit it. I am an Aristotelian. What I mean by that is that of the three predominant ethical theories, deontology, utilitarianism and virtue oriented ethics, the latter makes the most sense to me. It is the ethical theory which was promulgated by Aristotle. Jon Dahl gave an excellent introduction to ethical theory and comparison to software development. Initially, he alluded to the fact that determining what makes a good programmer has less to do with external signs, and more to do with the programmers habits. He briefly makes ethical comparisons of software development methodologies. In this sense, he starts to look at the human element of software development. The rest of the talk, however, makes comparisons between ethical theories and specific programming languages. Perhaps this is because he was at a Ruby conference. Ultimately, I think that a closer analogy can be drawn between specific programming languages and philosophical principles from Metaphysics or Ontology rather than Ethics. This is because languages are tools for expressing concepts. Ethics however, deals with humans and human society. The goal of Virtue Oriented Ethics is for the individual to achieve a state of Eudaemonia: human flourishing. Applied to software development we could say we wish the team or project to reach a state of flourishing, or Software Development Eudaimonia. As such, I think that comparison to ethical theories is more appropriate to things such as Software Development Methodologies or Project Management.

I am an Agilist (no surprise there). If you have ever had the good fortune (Eudaimonia is also sometimes translated as good fortune) to be on a highly Agile team, you probably have a sense of this flourishing. Notice how I used the comparative when describing the Agile team. Agility is not a binary state as much as it is a spectrum. Similarly, Eudaemonia can be achieved to varying degrees. The recognition of underlying rules or laws which help a society achieve such a state is codified as Natural Law. In so far that Agile methodologies work because of their recognition of humans at the core of software development, I think Agile comes close to describing a Natural Law of software development. Yet it is one thing to state a Law or set of Laws and another to develop a lawful society. Dahl brings this up when he talks about how the XP rules as they are promulgated are very deontological. Following the rules does not ensure that you will be a good programmer. This is interesting in that the people who came up with XP were good programmers. The generation of their rules probably was a long process of self reflection and attempts to make both their code and themselves better. So while the rules they promulgate may be used deontologically, the rules  themselves were likely developed via a more virtue oriented or utilitarian analysis. A common concern is how to get a team or company to 'become Agile'. Downloading lists of rules is easy, transforming a culture is not. Approaching Agility as attainable by degree seems to lead to better transformations. However these transformations are not simply replacing one deontological set of rules for another. People sense a real change in how they interact.

Therefore I posit that Agility is the Eudaimonia of Software Development. To follow the Aristotelian thought that virtue is taught by role models, perhaps a better use of the XP rules is as good models to others; sort of a goal state for developers working on their own virtue. Yet this presupposes that there are virtues inherent to achieving Agility. What are these virtues? Where would we look to find these virtues?

In his blog, Todd Hoff compares Agile as Aristotelian with Waterfall which he deems Machiavellian. In this, the core element which he recognizes is a scale between Trust and Fear. He presents the Waterfall world as being fear driven, whereas the Agile world requires teams built on trust. I think this a good place to start with analyzing Agile from a Virtue Oriented perspective. In many lists of Virtues, the concept of Trust is apparent. It is usually listed as Faith. In our modern minds, this word often is equated with a naive, unfounded belief. The way we use the word faith throughout our language indicates trust born from an observation of habitual behavior. We can say a dog is faithful, or I have faith in my friends, team members or boss. We say we are faithful to our spouses. This is language of Trust. In many of the classical virtue lists, Trust/Faith is a core virtue. This is similar to what we see in Agile transformations. The failure of many teams to transform to a higher state of Agility is often tracked back to embedded distrust within the culture.

In order to place the virtue of Trust in an Aristotelian context, it should be on a spectrum, with the virtue found at the mean of two extremes. So let us say that on one side we have distrust breeding fear. On the other side we have naive or blind trust, where we have no reason to really trust. The mean then is a Trustful state - where the team members both work to be Trustworthy/Faithful and based upon the actions of other team members they Trust or have Faith in them.


Naive TrustTrust/Trustworthiness Distrust/Fear


What then are some other Virtues embedded in Agile which help to promote Software Development Eudaemonia? The XP rules mentioned by Dahl have been noted as being somewhat limited in scope. So,while they may be a good guide for some of the team, they may not be the best model for general Agility. In their broad approach, the Agile Manifesto and Agile Principles are a better suited for guiding general virtuous development toward Agility. In my next posting(s) on this topic, I will go through these documents and highlight traditional virtues which are embedded in the behavior they are trying to model. I will then discuss how these behaviors and particular techniques from various Agile methodologies can help a team or individual increase specific virtues and achieve greater Agility.

Tuesday, January 4, 2011

What makes Agile work

In my career, I have seen team after team struggle to 'succeed' at implementing Agile. I asked a recent Product Owner who felt that the team had been partially successful, but still had a way to go, what he felt made Agile successful on his team. His answer was enlightening. He said 'the ability to change.' In essence, this is a tautology. Agility is the ability to change. It is why one would chose to implement Agile. It is not however, what makes Agile work. This is unfortunately typical. A team will focus on one practice or outcome of Agile as being the be-all of Agile. In so doing their focus creates false expectations and at the same time prevents them from focusing on making the changes necessary to harness Agile most effectively.

So what is it that make Agile work? Let us look at the Agile Manifesto and the Principles behind it. Over and over again, one concept is referred to: People develop software. (Humanitatem Progressio Progressus) In other words, Agile is successful when it recognizes that Human Beings are the core component of the development process; not tools, not methodologies, not practices, not languages. Once we recognize that Humans, and not just Humans in the broad sense, but specific individuals, we are faced with individuals who each bring specific strengths and weaknesses to the development effort. From here on out, everything else in Agile is simply about helping teams enhance the strengths and mitigate the weaknesses of individuals on them. The primary tool which Agile uses for this is tight feedback loops. Agile fosters communication so that the dangers of weaknesses can be exposed and avoided and strengths can be shared or leveraged quickly.

This brings me to the failure point for every team I have seen struggle with Agile. Something gets in the way of the communication. While I intend to post on technical issues as well, my primary focus for this Blog is to explore the ways communication breaks down on Agile teams and what tools Agile methodologies have to solve this. Where the methodologies do not propose a direct solution, I hope to bring you thoughts from practice and professionals on tactics used to bring Agile teams back on course, keeping the principles and the humanity of software development in mind.