Archive

Posts Tagged ‘BDD’

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…

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.

Automate acceptance/unit testing C++ in Xcode

April 13th, 2009 2 comments

In my quest to automate all repetitive tasks, setting up a Xcode project for unit testing (using Boost.Test) is in my crosshairs.  I’m in the process of adopting BDD, so you’ll see that terminology mixed with that of unit testing.

Plan

  1. List out all the manual steps.  I started with the process described by Richard Dingwall in a very nice tutorial here.
  2. Implement task in Applescript
Manual process

Ok, so here’s what I do when I start a new C++ project…

  1. File->New Project…
  2. Add Group “Features” @ [project-directory]/Features
  3. Add Group “Specifications” @ [project-directory]/Specifications
  4. Add Group “Boost Test Common” @ [project-directory]/Boost Test Common
  5. Add XcodeLogFormatter.h (allows Boost.Test reports to be properly displayed in Xcode build results; see below) and run_tests.cpp (Boost.Test’s main function) to Boost Test Common
  6. Add Features Target
    1. Add->”New Target”
    2. BSD->Shell Tool
    3. Name: Features
    4. Add run_tests.cpp to “Compile Sources”
    5. Add “/usr/local/include/boost-1_38/” to “Header Search Paths” of Features Target
    6. Add->New Build Phase->New Run Script Build Phase
    7. Script: “${TARGET_BUILD_DIR}/${EXECUTABLE_NAME}” (this causes the Features to be run every time the target is built)
  7. Add Specification (i.e. unit tests) Target: repeat step 6 above for “Specifications”
  8. Add->Existing Files->[boost unit test library]; check Targets: “Features” and “Specifications”
Applescript

Finally done!  Here’s the script and Xcode library script.

Not Doing Now

As I work, I make a list of things that would be nice to have, but are not important enough to think about right now and would take me away from my task:

  1. Put Boost Test Common files in a commonly accessible include folder

Source Code

XcodeLogFormatter.h (from http://richarddingwall.name/category/xcode/):

#include <boost/test/included/unit_test.hpp>

struct xcode_log_formatter :
public boost::unit_test::output::compiler_log_formatter
{
// Produces an Xcode-friendly message prefix.
void print_prefix(std::ostream& output,
boost::unit_test::const_string file_name, std::size_t line
{
output << file_name << ‘:’ << line << “: “;
}
};

run_tests.cpp (from http://richarddingwall.name/category/xcode/):

#define BOOST_AUTO_TEST_MAIN
#include <boost/test/unit_test.hpp>
#include “XcodeLogFormatter.h”

// Set up the unit test framework to use an xcode-friendly log formatter.
struct xcode_config {
xcode_config() {
boost::unit_test::unit_test_log.set_formatter( new xcode_log_formatter );
}
~xcode_config() {}
};

// Call our fixture.
BOOST_GLOBAL_FIXTURE(xcode_config);

(updated) Check out the finished AppleScripts:
1. main script @ http://seandenigris.com/blog/files/Make%20new%20C++%20project.scpt
2. Xcode handler library script @ http://seandenigris.com/blog/files/Xcode.scpt

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.

Behavior Driven Development

March 3rd, 2009 No comments

My adventure continues.  Today I’m exploring Behavior Driven Development, which seems to address my “lost in the jungle” relationship to TDD by starting with user requirements:

First reference, from the man himself – Dan North, the creator of BDD @ http://dannorth.net/introducing-bdd: 

I remember thinking “If only someone had told me that!” far more often than I thought “Wow, a door has opened.” I decided it must be possible to present TDD in a way that gets straight to the good stuff and avoids all the pitfalls.

Damn, sounds good so far!

The details:

  • Test method names should be sentences like testFailsForDuplicateCustomers.  The benefits are:
    • creates powerful documentation when combined with a utility (like AgileDox)
    • using “should” keeps you focused on what the class-under-test should do, and keeps you challenging whether it actually “should” do that – this guy is an artist :)
    • gives guidance when the test fails
  • Use behavior instead of test i.e. instead of “class ContainerTest,” write “class ContainerBehavior”
  • Continually ask “what is the next most important thing [behavior] the system doesn’t do?  This keeps you thinking in terms of business value
  • Requirements are actually behavior, so requirement analysis is actually behavior analysis.  For each user story, apply a Given/When/Then template to each relevent behavior:
    • Story – Customer withdraws cash: As a customer, I want to withdraw cash from an ATM, so I don’t have to wait in line at the bank)
    • Behavior – (Scenario 1) Account is overdrawn: Given that the account is overdrawn, And the card is valid, When the customer requests cash, Then ensure a rejection message is displayed, And ensure cash is not dispensed, And ensure the card is returned
  • Acceptance tests should be executable, analogous to unit tests.  He created JBehave for java.

Impressions: whhhewww.  I’m relieved that this isn’t yet another approach that must be learned from scratch.  It’s really just a metaphor (to quote Bob Martin) shift.  The techniques are identical to TDD, just looked at from the perspective of the users of the system.  What is the behavoir that the user wants in this stiuation – nothing to do with implementation!  This is great because that’s what the software is all about anyway!  It seems like TDD focused on the needs of the customer – perfect!

Bob Martin suggests that BDD really describes a finite state machine that could tell you all the possible combinations of behavior, and thus what tests to write and when you are finished (http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd).

Categories: Programming Tags: ,

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