Tuesday, July 25, 2006

Introduction to BDD (Behaviour Driven Development)

BDD is an evolutino of TDD. Those that are doing TDD correctly are aware they are writing in code small specification documents. The code is then written to meet the specification, then the code is checked automatically against the specification using a tool that understands both documents. To call these specifications tests is backwards, as there is nothing to test at the point they are written. More importantly as tests they have an implied scope (unit tests test methods on classes one at a time). If you write specifications instead, then a different scope seem far more appropriate (eg. In context X these things should be true.)

When I first heard about this concept the implementations of frameworks were nothing more than Nunit and Junit with the names changed. Looking at rSpec however things have come along well. Yet again Ruby lends itself well to creating a DSL. In this case for code specification.

Here is an example from rSpec's "RSpec on Rails".

context "The Person model" do
fixtures :people, :animals

setup do
# fixtures are setup before this
end

specify "should find an existing person" do
person = Person.find(1)

person.should_equal people(:lachie)
person.name.should_equal 'Lachie'
end

specify "should have animals" do
people(:lachie).should_have(2).animals
end

teardown do
# fixtures are torn down after this
end
end


I love it!

Check out Dave Astel's great introduction to BDD.

SVN Berkley DB Lock

The server's drive got full and that broke subversion last night. The Berkeley databases got locked and wouldn't unlock. I couldn't do an svn recover \repository\path as it wouldn't release the lock.

Finally I realised all I needed to do was reset the svnserver service.
I lost a good hour of my life looking for solutions, hopefully you won't have to.

xUnit with a twist

Imagine nUnit coupled with Object Mother and dependency injection.

You would be able to write a test and specify the test objects you wish to manipulate by adding parameters to the method.

[Test]
public void adding_a_task_to_a_project_causes_the_tasks_predicted_start_date_to_be_set( IProject mockProject, Task washCloths )
{
// ... test stuff as normal
}

Parameters with the name 'mockX' could cause mock instances to be created. 'washCloths' would be an example of a named instance, so a specific instance of task would be created in a known state. 'anyProject' could return a simple project instance.

Just a thought... but I like it.

Thursday, July 13, 2006

Now there is no excuse not to try Ruby!

Check out http://tryruby.hobix.com

It's a ruby interactive tutorial in a browser (thanks to 'why the lucky stiff')


Wednesday, July 12, 2006

Buildix: Development Infastructure in an instant

Check out Buildix.

Subversion, Cruise Control, Tracs all preinstalled and running from a KNOPPIX disk.

GitHub Projects