Robby on Rails: Tag bdd

Spec Your Views

Robby Russell — Thu, 02 Aug 2007 02:00:00 -0500

I meant to work on this post… oh about 7 months ago.

Way back in January (7 months ago), Jamis Buck posted an article titled, Testing your views, which gave a few tips on using Test::Unit to, as the title suggests, test your views.

While, I’m not going to rewrite everything that Jamis wrote, I’d like to show you how to test these views with RSpec. (you might take a moment to quickly read his post…)

In this example, I’m going to show you how we’re able to write specs for the following RHTML, which you’ll notice matches the code that he wrote tests for.


  <% if @user.administrator? %>
    Hi <%= @user.name %>! You appear to be an administrator.
    <%= link_to "Click here", admin_url, :id => "admin_link" %>
    to see the admin stuff!
  <% end %>

Jamis writes, “The only really significant thing you ought to be testing here is that the admin link only shows up for administrators. “

So, let’s do just that, but with RSpec.

I’m not sure how Jamis is handling his view tests, but we’re going to approach our view specs, much like we approach our controller specs, with the use of mocks and stubs, because we really don’t need to spec any of our models at this level in the application.

Tip: Write specifications for your models… in your model specs not in your controller or view specs.

The first thing that we’re going to do is setup a custom spec helper, because for something like an mocked user, will probably get reused in other areas of the user interface. Spec helpers are essentially modules that you can include in your RSpec descriptions (the block that starts with describe) and reuse.

In this spec helper, I’m going to include two methods, to mock the User model and stub out any of the methods that are necessary for spec’n this view.


module MockUserHelper
  def mock_normal_user
    user = mock(User)
    user.stub!(:administrator?).and_return(false)   # <--- NOT an admin
    user.stub!(:name).and_return('David Chelimsky')
    return user
  end

  def mock_admin_user
    user = mock(User)
    user.stub!(:administrator?).and_return(true)    # <--- IS an admin
    user.stub!(:name).and_return('Aslak Hellesoy')
    return user
  end
end

In the mock_normal_user method, we’re constructing a mock object and stubbing out the methods that we see are being called in the RHTML code. In mock_admin_user, we’re basically doing the same thing, but just stubbing the administrator? method to return true for this mock user.

By stubbing these methods, we’ll be able to send a non-ActiveRecord object to the view and have it render without knowing the difference. For example, the if @user.administrator? condition will return true or false, depending on how we stubbed it.

For more information on mocks and stubs, read here.

Now that we have our spec helper, let’s go ahead and dive into a few specifications for the view.


describe "index page" do
  include MockUserHelper

  it "should render an admin link for an admin user" do
    assigns[:user] = mock_admin_user
    render 'index'
    response.should have_tag('a#admin_link')
  end

  it "should not render an admin link for a normal, non-admin user" do
    assigns[:user] = mock_normal_user
    render 'index'
    response.should_not have_tag('a#admin_link')
  end
end

Please note: This code example is only longer than the one shown by Jamis because he didn’t include how he setup all his user sessions/objects. ;-)

When these specs are run, we can see the following results.

Pretty output courtesy of RSpec + TextMate bundle

Great, we’ve been able to write specifications for our Rails views without a lot of pain. Stay tuned for more posts on this topic as I continue writing about how Designers and Developers can work together, in harmony. (see my last post on this topic)

For more information on adopting RSpec, please visit the RSpec project homepage.

All the cool kids are doing it... why aren't you?

Robby Russell — Thu, 17 May 2007 13:15:00 -0500

Josh Knowles just mentioned an article written by David Chelminsky, titled, an introduction to RSpec – Part I. In this article, David introduces you to some of the new language that appeared in some of the recent versions of RSpec as well as give you a complete tutorial on building some specs.

Last night, I had the opportunity to sit down with Aslak Hellesøy and David Chelimsky for a few hours and talk about my experiences of using RSpec at PLANET ARGON and how it’s helped us redefine and evolve our process. In particular, how RSpec has helped us reshape our process of gathering user interaction specifications from our Interaction Design team and business rules from our clients.

If you’re in town and are using RSpec… or are thinking about using RSpec… and see these guys… thank them for all the hard work that they’re doing… and of course, if you run into anybody else on the team... do the same. :-)

Aslak Hellesøy and David Chelimsky

Also, by the end of the conference... Graeme and I are hoping to have a small project done to help encourage more adoption of Behavior-Driven Development

You Might Learn Something at the Back of the Train

Robby Russell — Thu, 19 Apr 2007 11:13:00 -0500

I love to look at other peoples code. Initially, that’s what got me excited about Open Source software. Otherwise, I was looking at small snippets on various developer sites and really not getting the complete picture for how everything tied together.

Last night, I finally had a chance to checkout the sample caboose application, which was created as a way for people to get an idea for how some of developers in caboo.se are putting together their applications.

Some things that you might want to check out it’s using…

It’s definitely worth taking 15 or so minutes to check it out and get some fresh ideas.

There are a few things that I’m not quite sure that didn’t quite make sense, so… perhaps I’ll submit a patch. :-)

svn co svn://caboo.se/plugins/court3nay/empty_apps/tags/v_003

Have fun!

BDD is still kinky

Robby Russell — Tue, 10 Apr 2007 16:51:00 -0500

I still believe that Behavior-Driven Development is kinkier than Test-Driven Development...

Embracing Failure, part 1

Robby Russell — Tue, 10 Apr 2007 16:38:00 -0500

I’m currently reading To Engineer is Human, by Henry Petroski and found the following applicable to software development and managing client and customer expectations.

“As much as it is human to make mistakes, it is also human to want to avoid them. Murphy’s Law, holding that anything that can go wrong will, is not a law of nature but a joke. All the light bulbs that last until we tire of the lamp, all the shoelaces that outlast their shoes, all the automobiles that give trouble-free service until they are traded in have the last laugh on Murphy. Just as he will not outlive his law, so nothing manufactured can be or is expected to last forever. Once we recognize this elementary fact, the possibility of a machine or a building being as near to perfect for its designed lifetime as its creators may strive to be for theirs is not only a realistic goal but also a reasonable expectation for consumers. It is only when we set ourselves such an unrealistic goal as buying a shoelace that will never break, inventing a perpetual motion machine, or building a vehicle that will never break down that we appear to be fools and not rational beings.”

I’m sure that most of us are guilty of having high expectations for products that we purchased. (why does my ipod screen scratch so easily when in my pocket?) We also set high expectations for the code that we develop, which is why we (hopefully) continue to refine our process. We’re bound to time and budget constraints, which often prevent us from testing every imaginable edge case. Given our constraints, problems are almost always going to arise. It’s no wonder that we see Test-Driven Development as an important part of a healthy development process. We want to catch our failures as early as possible.

Our clients often have high expectations and it’s almost always very reasonable. That’s not to say that some clients will not have highly irrational expectations. It’s our job to manage these expectations as best as possible.

Do we mislead our clients by convincing them that our TDD/BDD process is going to prevent any bugs from creeping from the woodwork after the development cycle is finished?

“I thought that we paid you to fully test the code?”

Really… is that even possible? Can we predict (and test) every possible interaction within an application? Highly unlikely.

What we can do is plan for and embrace failure. We can help our clients understand that almost every application needs to be maintained after it’s initial development cycle. Bugs are inevitable and there needs to be a clear process for handling them.

Perhaps I’m abusing the bug fixing process by calling it a failure… but I’ve also found that yes… many bugs are due to failure. Whether that be a failure to specify application behavior, a failure to understand the project goals, a failure in communication, ...or maybe a failure in our software architecture. We’re constantly failing.. and it’s okay!

IT’S OKAY TO FAIL! (some of the time…)

“No one wants to learn by mistakes, but we cannot learn enough from successes to go beyond the state of the art. Contrary to their popular characterization as intellectual conservatives, engineers are really among the avant-garde. They are constantly seeking to employ new concepts to reduce the weigh and thus the cost of their structures, and they are constantly striving to do more with less so the resulting structure represents an efficient use of materials. The engineer always believes he is trying something without error, but the truth of the matter is that each new structure can be a new trial. In the meantime the layman, whose spokesman is often a poet or writer, can be threatened by both the failures and the successes. Such is the nature not only of science and engineering, but of all human endeavors.”

As we’re creating these virtual structures… are we really taking the time to reflect on our failures? This is why some teams adopt practices like iteration retrospectives and post-mortems.

I’ll end this with a few questions, which I hope that you’ll share your experiences about…

In what ways is your team embracing the failures of your development projects?
How do you help manage your clients expectations… so that they too can plan for and embrace failure? Isn’t their new business venture on the web… likely to experience some failure?

We have so much to learn…

On Apologies

Robby Russell — Thu, 15 Feb 2007 16:01:00 -0600

Recently, Seth Godin posted a short blog post, titled, Apologies, ranked, which points out several ways of apologizing. When you work in a service industry, it becomes very important to develop good apology skills. Let’s be honest for a moment. Not everything works out for the best in every customer experience. Sometimes it’s their fault and many times… it’s our fault.

In response to Seth’s post, Marc Chung has written up a similar post that adapts this to software bugs, titled, Seth on Fixing Bugs.

It’s worth a read and definitely relates to the communication issues that we keep talking about within the Dialogue-Driven Development community and how that can translate to a healthy testing process with BDD.

Thoughts?

Be Careful that you don't Stub your Big Toe

Robby Russell — Tue, 13 Feb 2007 01:09:00 -0600

In a project that I’m currently working on, we’re handling recurring payments for subscribers. I’ve decided to play with a different payment service API on this project (TrustCommerce), which supposedly has one of the easier systems to handle recurring payments as well as one-time charges to the same credit cards. They store all the credit card data so that our delivered product to the client is CISP-compliant.

I came across the TrustCommerce Subscription plugin for Rails, which does just everything that I need to do in this first product release… as well as things that aren’t requirements just yet.

Well, I got my test account from TrustCommerce and was working on some RSpecs to test my new subscription and noticed that it was failing. After some snooping around the error responses, I realized that… test accounts don’t give you the ability to test the Citadel features of TrustCommerce. It’ll be another week or so before finish getting our account setup, so what am I to do? I really want to finish writing these specs and move on to the other portions that are dependent upon this working.

Suppose that you were going to perform something like this in an AR callback.


class BillingDetail < ActiveRecord::Base

  # validations    

  before_create :store_credit_card_data_with_trust_commerce

  private 

    def store_credit_card_data_with_trust_commerce
      # some of this is still test data... prettyu much copied from the README
      # TODO: refactor... but keep me out of controllers!
      response = TrustCommerceGateway::Subscription.create(
          :cc =>  self.credit_card_number, 
          :exp => '0412', 
          :name => self.customer_name,
          :amount => 1,
          :cycle => '1y',
          :demo => 'y'
        )

      if response['status'] == 'approved'
          self.billing_id = response['billingid']
        else
        # handle failure
        end
    end
end

Enter Mock Objects

Since I am unable to succesfully use the TrustCommerceGateway::Subscription.create method until I get our real account, I needed a simple way to emulate the interaction with the web service.

This can be done by using a Mock object, which RSpec provides for you.


TrustCommerceGateway::Subscription.stub!(:create).and_return( {expected response} )

Let’s look at the following spec file (much of it removed to protect the innocent).


module ValidBillingDetail
  def valid_attributes
    { # a hash of valid key/values for this model }
  end

  def approved_trust_commerce_subscription
    { 'status' => 'approved', 'billingid' => '1093423' } 
  end
end

context "A new billing detail" do
  include ValidBillingDetail

  setup do
    TrustCommerceGateway::Subscription.stub!(:create).and_return( approved_trust_commerce_subscription )
  end

  # bunch of other specs

  specify "should store new billing info with 3rd party API and store the billingid" do
    @billing_detail = BillingDetail.create( valid_attributes )
    @billing_detail.billing_id.should_not_be nil
  end
end

You’ll notice a few things. First, you’ll see that I’ve stubbed the create method and when it is called in the method in my model, it’ll return the hash that I’ve specified.

TrustCommerceGateway::Subscription.stub!(:create).and_return( approved_trust_commerce_subscription )

In the spec, you will see that I am checking that that the .billing_id.should_not_be nil. If you look back in the method in the model above, you will notice that an approved subscription returns a billing_id, which is set when the transaction is successful.

This is working out great for me and because the documentation is fairly easy to follow, I’m going to be able to mock much of the behavior that I’ll be using in the application, without needing to even connect to their API.

If you’re using RSpec, I highly encourage you to read more about mocks objects.

RSpec Bundle for TextMate

Robby Russell — Mon, 12 Feb 2007 07:58:00 -0600

Just a quick follow up to my post last night, Sharing Custom TextMate Bundles with Subversion. It appears that I missed the RSpec bundle for TextMate, which is listed on the RSpec webpage.

Install the RSpec Bundle

Installation is quite simple, just change directories to your TextMate bundle directory.


    $ cd ~/Library/Application\ Support/TextMate/Bundles/

Check out the RSpec bundle from the subversion repository.


    $ svn co svn://rubyforge.org/var/svn/rspec/trunk/RSpec.tmbundle
    # lots of files...
    A    RSpec.tmbundle/Support/spec/fixtures/example_failing_spec.rb
    A    RSpec.tmbundle/Support/spec/fixtures/example_passing_spec.rb
    A    RSpec.tmbundle/Support/spec/spec_mate_spec.rb
    Checked out revision 1489.

Now, just reload your bundles in TextMate and you’re good to go!

Bundles > Bundle Editor > Reload Bundles

I’d like to thank Aslak Hellesøy for pointing me to this and for also providing me with the correct subversion URL, which is currently outdated on the RSpec page until the next release.

Is BDD kinkier than TDD?

Robby Russell — Thu, 08 Feb 2007 13:20:00 -0600

If you’re in need of a compelling reason to switch from Test-Driven Development to Behavior-Driven Development... consider this.

“BDD sounds kinkier.” -Michael K. Loukides, Book Editor for O’Reilly

...on that bombshell... I am going to suggest that this be used as the official BDD logo.

There you have it. Deep down… the biggest reason that I switched from Test::Unit to RSpec... was the sex appeal. ;-)

What was your reason?

The Zen of Auto Rspec

Robby Russell — Wed, 10 Jan 2007 11:08:00 -0600

Several months ago, I heard that people were using a program called autotest to have their tests continue to run as you made changes to your code base, which comes with ZenTest. It’s a really nice tool written by Ryan Davis and I hadn’t gotten a chance to play with it as of yet. Well, our team isn’t spending too much time in the test/ directory these days as we jumped ship near the end of last summer and found ourselves hanging out on the Isle of BDD. The locals are quite thoughtful about these sorts of things.

I just started working on a project that has been under development for several months and as I’m getting to learn the ins/outs of the system, I find myself having to rerun the specs, which can take quite a bit of time watching. Watching your specs or tests run sometimes is as productive as watching your code compile. Oddly enough, this is as close to compilation as we really get when working with Ruby on Rails… and it’s a productivity killer for me.

There Must Be a Better Way!

So, I did a quick google search and found an announcement for Rails that ran specs through ZenTest. This was exactly what I was searching for!

Some requirements

Please makes sure that you have the following gems installed in your development environment as they are dependencies to make this all work.

zentest
diff-lcs


$ sudo gem install zentest diff-lcs

note I’m going to assume that you have rspec and rspec for rails installed… if not… tsk. ;-)

Install RSpec autotest


$ script/plugin install http://svn.caldersphere.net/svn/main/plugins/rspec_autotest

If you’re using subversion, you might consider installing it as an external.


$ script/plugin install -x http://svn.caldersphere.net/svn/main/plugins/rspec_autotest

Running RSpec autotest

This is where it gets tricky. ;-)


$ rake spec:autotest

Now, you can keep a terminal window open and autotest will watch your application and detect when files change. When they change, it’ll attempt to rerun your specs (specifically those that changed). This helps save you the time of having to rerun all your specs throughout the development process and keep your spec:all sanity checks for when you’re about to commit code to your repository.

I’ll post another entry in the next few days to show you how you can use Growl with RSpec Autotest to keep you from having to look at your terminal all the time.

Until then… have fun!

The Circular Perspective of BDD

Robby Russell — Thu, 12 Oct 2006 09:56:00 -0500

A few weeks ago, Brian Ford was in my office and we were discussing BDD and how we can make this process even easier for our clients to understand… much less our own internal staff. With all concepts, each person has their own idea about what it is, why it is important, regardless of whether or not it’s accurate. This can cause some people to not find a good need for some practices.

During our discussion, Brian grabbed one of my whiteboard markers and drew diagrams to explain how he saw BDD vary from TDD. He has since posted an article on his blog titled, what’s it worth to me, and discusses his circular view of Behavior-Driven Developent and the importance of using Dialogue to evolve shared meaning.