Archive

Archive for the ‘Behavior Driven Development’ Category

Debugger Driven Development

December 4th, 2010 4 comments

An amazing feature of Smalltalk is that you can create methods right from the debugger.  This fits nicely with “write the code you wish you had.”

  • First, you write a test calling whatever methods you want (even if they don’t exist)
  • When you run the test, a debugger pops up with a create button

  • Like magic, with a push of that button, a method skeleton appears in which you fill the implementation

Field Report

Now this is where things get creepy…  It’s after midnight, and I just want to finish one last thing.  You see, I’ve been implementing a very basic Cucumber-like framework for acceptance tests in Squeak, and there’s just one thing left to do.  I’ve got helper methods that turn given/then/when descriptions into methods that define the steps, like this:

As you can see, #given: transforms the description string into a camel case method name.

All I had left to do was handle the case where the method didn’t exist yet.  In cucumber, templates are passed to the command line to be pasted into the step definition file.  Oh, I’ve got it, the transcript is like command line output, I’ll paste it there!  Let me just see what this debugger is about…

When I took a closer look, I started laughing and couldn’t stop…

Smalltalk handed me a magic Cucumber-step-definition-template-generator!  I checked one more item on my todo list and clicked the magic button.

BDD in Squeak Smalltalk: An exploration

April 27th, 2010 4 comments

Coming from Ruby, I’m obsessed with Behavior Driven Development.  The community (e.g. Rspec, Cucumber) is alive, and there is a body of practices to follow.

Since TDD was born in Smalltalk, I expected to find the same energy and guidance in Squeak.  Squeak represents the most profound, empowering environment I’ve ever seen (I will never go back to C, C++, or even Ruby – which misses the boat by not being a living system).  However, the testing situation seems frozen in the early days.

My intention is to create do a series of experiments, which will lead to BDD best-practices in Squeak.  My vision is code that is pulled into existence by what matters to its users, that is easy to understand, and easy to change.

I’ll keep you posted…

Autospec with custom directory/file names

January 17th, 2010 No comments

Autotest is a great time-saver when doing BDD (or TDD for the less-enlightened, lol).  Autospec seemlessly integrates Rspec.  However, if you don’t use the expected “spec/*_spec.rb” structure, autotest will not find your specs – or examples, as I call them.

It is very easy to use whatever structure you want using the following steps:

Telling Autotest to use Rspec as the test runner

The first thing you want to happen is for Autotest to use Rspec as the test runner.  This usually happens automatically using autospec, which tests for the presence of the spec directory.  Since we do not want a spec directory, we must tell explicitly tell Autotest to do this.  So:

Step 1: in your project directory create a file autotest/discover.rb with the following line:

Autotest.add_discovery { "rspec" }

Teaching Autotest about our custom directory structure

In order to do this, we have two options.  If we want to use the same structure for all our projects, we can put a file in our home directory, otherwise we can add custom files to each project directory.

Step 2: create a file .autotest with the following code:


class Autotest::Rspec < Autotest remove_method :consolidate_failures def consolidate_failures(failed) filters = new_hash_of_arrays failed.each do |spec, trace| if trace =~ /\n(\.\/)?(.*example\.rb):[\d]+:/ filters[$2] << spec end end return filters end remove_method :add_options_if_present def add_options_if_present # :nodoc: File.exist?("examples/spec.opts") ? "-O examples/spec.opts " : "" end end Autotest.add_hook(:initialize) {|at| %w{.git .svn .hg .swp .DS_Store ._* tmp}.each do |exception| at.add_exception(exception) end at.clear_mappings # take out the default (test/test*rb) at.add_mapping(%r%^(examples|third_party)/.*_example.rb$%) { |filename, _| filename } at.add_mapping(%r%^lib/(.*)\.rb$%) { |_, m| ["examples/#{m[1]}_example.rb"] } at.add_mapping(%r%^examples/(example_helper|shared/.*)\.rb$%) { at.files_matching %r%^(examples|third_party)/.*_example\.rb$% } #nil }

Let’s take it piece by piece:


def consolidate_failures(failed)
  filters = new_hash_of_arrays
  failed.each do |spec, trace|
    if trace =~ /\n(\.\/)?(.*example\.rb):[\d]+:/
      filters[$2] << spec
    end
  end
  return filters
end

This method tells Autotest which test files have failed by pulling the file names out of the test output. Since autospec looks for *_spec.rb files, it will not find our custom files. I use *_example.rb filenames, so you should replace that part of the regex with whatever you use.


def add_options_if_present # :nodoc:
    File.exist?("examples/spec.opts") ? "-O examples/spec.opts " : ""
  end

This method tells Rspec where to find an option file. Again, replace the details with whatever you use.

In Autotest.add_hook(:initialize):

  %w{.git .svn .hg .swp .DS_Store ._* tmp}.each do |exception|
    at.add_exception(exception)
  end

This tells Autotest to ignore certain files that are irrelevent to testing

at.clear_mappings

This tells Autotest not to use any other mappings i.e. the default test/test*rb, or Rspec’s spec/*_spec.rb

at.add_mapping(%r%^(examples|third_party)/.*_example.rb$%) { |filename, _|
  filename
}
at.add_mapping(%r%^lib/(.*)\.rb$%) { |_, m|
  ["examples/#{m[1]}_example.rb"]
}
at.add_mapping(%r%^examples/(example_helper|shared/.*)\.rb$%) {
  at.files_matching %r%^(examples|third_party)/.*_example\.rb$%
}

This is the meat of the customization. It tells Autospec, based on which files have changed, which tests to run. Replace my regexes with your custom matches.

The end

Once you have added both these files, running autospec from your project directory will work as it should!

BDD in the field

December 3rd, 2009 2 comments

I am on fire about Ruby.  I always hated Objective-C’s weirdness (coming from C++), and read the most awesome idea recently – given the amazing power of modern computers (now pay attention, this is the good part): writing code in anything but the highest level, easiest language is… premature optimization!!!  The instant I read that statement (sorry to the author, I can’t remember where), I knew it was true.  Add that you can drop down from Ruby to lower level languages where you need extra speed, and that MacRuby and HotCoca are going to make it ridiculously easy to use Cocoa via Ruby and…

That’s it – I’m hooked.  To get myself up to speed in Ruby and Cocoa, I’m re-writing the examples from Aaron Hillegass’s awesome book Cocoa Programming for Mac OS X.  I’ll be writing about the intricacies of BDD in Ruby using Xcode, and I’ll be posting all the code, as well as custom file and project templates for Xcode.

Why Behavioral/Test Driven Development?

March 20th, 2009 No comments

I’m so clear on the “how” of BDD.  What I haven’t been connected to is the underlying motivation, the first principles from which all the techniques flow.   So I decided to start collecting them in one place (here, lol)…

  • Driving is the key word.  Emergent Design is the result Testing is a bonus.  The real juice is that the specifications actually drive the code to achieve its objective as simply as possible

Misc. BDD thoughts

March 6th, 2009 No comments
Categories: Behavior Driven Development Tags:

Interview of Dan North and Elizabeth Keogh

March 5th, 2009 No comments

The video of the interview is here.

First you get the UI, behind that there is code that gives benefit to the UI, and behind that there’s code that gives benefit to that piece of code, is smaller and more specific bits until the feature works.  The Domain Language is used all the way through.  Dan North tells a story…  While the developers were struggling with how to handle credit derivatives, a domain expert (a former trader) came by.  Because the developers were talking in the Domain language, the expert didn’t know they were even talking about code.  He thought they were talking about derivatives themselves and explained exactly how they work, giving them the algorithm.  

Scenario (and example) are words that the customer has a natural understanding for (unlike use case), that flesh out behaviors: given this situation, what to you want the software to do – what is the outcome?

  • Stakeholder: someone who has an interest in the work being done
  • Business analyst: expert in helping stakeholder articulate what they want in abstract terms e.g. “withdraw cash”
  • Tester: gets concrete with it e.g. “what does withdraw cash mean?  If I have $100 and withdraw $20, what is the result?”

This eliminates misunderstanding between the stakeholder and the developers as to what “done” actually means.

Using “should”  has two benefits.  Firstly, it forces you to focus on the class under test, because behaviors that don’t belong to that unit will not fit the “should” format.  Also, it allows the space to continually question “should it actually do this?”  This will have the documentation (the tests) naturally evolve with your understanding of the domain.

North describes different methodologies as:

  • Top-down – start with one big unit and keep breaking it up into smaller pieces
  • Bottom up – start with frameworks/architects and hope to solve the problem
  • Outside-in (BDD) – using the language of the domain, distinguish outer-most layer (e.g. scenarios) and work in from there.  The inner-most layer is the domain itself.  The UI is the third layer, which describes how the user interacts with the software.  In total, the question is “how do I describe software [interaction method] that [behavior in domain]?”  e.g. “how do I describe software [on the web] that [helps me plan the best shipping routes]?”

He concludes by suggesting that developers who are ingrained in the domain language can actually become part of the process of discovering business value, as they bring their level of understanding to the domain.

windows 7 product key

windows 7 product key

windows 7 key generator

windows 7 key generator

free winrar download

free winrar download

winzip activation code

winzip activation code

free winrar

free winrar

winzip free download

winzip free download

winrar free download

winrar free download

winrar download free

winrar download free

winzip free download full version

winzip free download full version

windows 7 activation crack

windows7 activation crack

windows 7 crack

windows 7 crack

free winzip

free winzip
\n