exceptionz

Thoughts on Technology, Methodology and Programming.

Archive for August, 2006

Ruby on Rails testing links

Posted by Marcus Wyatt on 31 August 2006

Following is a few links to RoR Testing tutorials:

Not a bad introduction
http://blog.new-bamboo.co.uk/articles/2006/08/01/rails-tdd-you-never-know-when-the-brakes-might-fail

In depth testing walk through. Long.
http://grayproductions.net/ruby/first_steps.html

Another walk through. Not Rails. Long also.
http://www.rubycentral.com/articles/pink/index.html

ActiveTest. Looks interesting but not so interesting that I would use it.
http://www.mathewabonyi.com/articles/2006/08/14/activetest-rails-style-testing

Autotest (and Zentest). Very useful for hard core tdd.
http://nubyonrails.com/articles/2006/04/19/autotest-rails

Code coverage tool. This is a must and is dead easy. There is no reason why you shouldn’t use this.
http://eigenclass.org/hiki.rb?rcov

Testing cheat sheet. Big list o’ asserts http://nubyonrails.com/articles/2006/08/24/ruby-rails-test-rails-cheat-sheet

Misc stuff…

Coloured test output
http://errtheblog.com/post/15

Several articles about ruby-prof on this blog http://on-ruby.blogspot.com/

Memory Leak Testing.
http://scottstuff.net/blog/articles/2006/08/17/memory-leak-profiling-with-rails

Kent Beck Podcast. Worth a listen.
http://www.itconversations.com/shows/detail301.html

Advertisements

Posted in RoR | 3 Comments »

Behavior-Driven Development Framework

Posted by Marcus Wyatt on 29 August 2006

NSpecify.Framework

Test-Driven Development has jumped the chasm to general acceptance. This is a good thing, but like Dave said in the Google video he presented, there are still a high percentage of people who practices Test-Driven Development badly.

On the other side of the coin, there is also people who is practicing Behavior-Driven Development while their doing Test-Driven Development.

So what is the difference?

In my opinion, most people think that Test-Driven Development is about Testing. When you explain that Test-Driven Development is really at its hart a design process, they squawk at you and give you a look like you have lost your mind.

I see Test-Driven Development performing the following roles:

  • Design process
  • Behavior Specification
  • Requirements Capturing
  • Regression Test Suite

For this reason I think we need a Behavior-Driven Development framework and NSpecify is an attempt to bridge this gap.

Here is an example of a Specification for a calculation domain object class:

using NSpecify.Framework;
 
namespace SampleBehaviour
{
  [ Functionality() ]
  public class Calculation
  {
    int one = 1;
    int two = 2;
 
    [ Specification() ]
    public void OnePlusOneMustEqualTwo()
    {
      Specify.That( one + one ).Must.Equal( two );
      Specify.That( two ).Must.Be.GreaterThan( one );
      Specify.That( two ).Must.Not.Equal( one );
    }
  }
}

If you would like to get a alpha release of the NSpecify.Framework and a NUnit install that integrates with NSpecify. You can download the framework and NUnit 2.2.8(.NET 2) or NUnit 2.4 Beta 1 (.NET 2) install.

 

tags: , ,

Currently listening to: Sea (PFM Mix) – Winamp *** 96. 10 – Saint Etienne – The Sea (PFM Mix)

Posted in BDD, TDD | Leave a Comment »

Behavior-Driven Development

Posted by Marcus Wyatt on 29 August 2006

Behavior-Driven Development (BDD) is an evolution in the thinking behind Test-Driven Development. It pulls together strands from Test-Driven Development and Domain-Driven Design into an integrated whole, making the relationship between these two powerful approaches to software development more evident.

It aims to help focus development on the delivery of prioritized, verifiable business value by providing a common vocabulary (also referred to as a Ubiquitous Language) that spans the divide between Business and Technology.

It presents a framework of activity based on three core principles:

BDD relies on the use of a very specific (and small) vocabulary to minimize miscommunication and to ensure that everyone – the business, developers, testers, analysts and managers – are not only on the same page but using the same words. For people familiar with the concept of Domain-Driven Design, you could consider BDD to be a Ubiquitous Language for software development.

It must be stressed that BDD is a rephrasing of existing good practice, it is not a radically new departure. Its aim is to bring together existing, well-established techniques under a common banner and with a consistent and unambiguous terminology. BDD is very much focused on “Getting the words right” and this focus is intended to produce a vocabulary that is accurate, accessible, descriptive and consistent.

In fact “Getting the words right” was the starting point for the development of BDD, and is still very much at its core, but the power of getting the words right has led to some insights and extrapolations that have helped us to better understand our approach and to extend it.

From behaviour-driven.org

So you’ve read the post. Want to know more? Maybe you should test a C# version of a BDD framework. I would like to get people who would be interested in alpha testing NSpecify. If you think you might be interested, download the NSpecify framework and the NUnit install that incorporates the NSpecify integration. Leave me a comment of your initial thoughts surrounding the framework.

Thanx.

Posted in BDD, TDD | Leave a Comment »

Applied Test-Driven Development Video

Posted by Marcus Wyatt on 29 August 2006

Jean-Paul Boodhoo posted a tutorial video on his site where he walks you through writing a Simple Web Application Test-Driven. He utilizes Resharper 2.0, NUnit and Rhino Mocks in the demonstration. For anybody wanting to get into TDD, this video will definably help you grow your TDD skills.

You can download the video here and use Swiff Player to view the video.

It is interesting to watch him use all the cool Resharper features, but what I’ve found and is very apparent in the video, is the productivity gains you get from using the shortcut keys. Suddenly writing a DTO object takes only seconds, where typing the DTO by hand takes a while. If you want to learn the Resharper shortcuts, here you can find a pdf describing the default keymap of Resharper 2.0.

Personally I use NMock2 to mock my external dependencies. I like the syntax of NMock2. What you loose by using NMock2 is refactoring support in your expectations. This is due to NMock2 using strings to specify the method names. But I must say that Rhino Mock look interesting.

tags: , , ,

Posted in TDD | Leave a Comment »

Source Formatting for Windows Live Writer

Posted by Marcus Wyatt on 26 August 2006

Everyone know what a pain it is to post source code to a blog and having the source code formatted correctly. Well, Norbert Eder at dotnet-blog created a source formatter plug-in for Windows live writer. It works great and all you need to do is download the plugin and copy it to the plugins-directory of your Windows Live Writer installation.

The plugin supports the following languages:

  • C#
  • Java
  • JavaScript
  • MSH
  • Perl
  • T-SQL
  • Visual Basic

This is how some code appears on my blog: 

[ Initialize() ]
public void Setup()
{
  mock = new Mockery();
  persist = mock.NewMock( typeof( IPersistance ) ) as IPersistance;
  customer = new Customer( 123 );
}
[Cleanup()]
public void Cleanup()
{
  mock.VerifyAllExpectationsHaveBeenMet();
}
 
[ Specification() ]
public void ShouldLoadCustomer()
{
  object[] param = new object[] { 123 };
  Expect.Once.On( persist ).Method( "Load" ).WithAnyArguments().Will( Return.Value( customer ) );
  Customer expectedCustomer = persist.Load( 123 ) as Customer;
  Specify.That(expectedCustomer.Id).Must.Not.Be.Null("The Customer Id must not be null.");
  Specify.That(expectedCustomer.Id).Must.Equal(123, "The customer id's aren't equal");
}

You can find the download for the formatter here.

tags: , ,

Currently listening to: ow 4 – Winamp *** 16. Anthony Pappa – Interflow 4

Posted in Software | 1 Comment »

Test-Driven Development Doubts

Posted by Marcus Wyatt on 11 August 2006

Alex Bunardzic made the following comments in his post:

These contract- and test-driven development disciplines sound really good in theory, however in everyday practice they seem to offer dubious benefits.

The problem is as follows: If a software developer is deemed not sufficiently reliable when writing a program that governs the interaction inside the system, a harness called contract-driven or test-driven is placed upon that developer. What the methodology is saying to him is: “We’ve noticed that you tend to make plenty of mistakes when programming the system. In order to avoid making those glaring mistakes, we want you to stop and write a contract first. Or, alternately, stop and write a test first. That’ll make sure that the mistakes won’t happen again.”

Sounds good? Perhaps, but there is one glaring omission that had just slipped in. And the omission is: what makes us think that a person who is not competent enough to write a reliable program would all of a sudden be competent when it comes to writing a contract, or a test? If we examine those contracts and tests, we’ll see that the same omissions in logic, once found in the code, are now infesting the contracts/tests.

So we see that the only people who are capable of writing robust, reliable contracts and tests are the people who are capable of writing reliable, robust programs in the first place. And if that’s the case, what’s the point in slowing them down and forcing them to stop and write those bloody contracts/tests?

I don’t agree with Alex and see the world as follows:

When you look at TDD as an XP practice in isolation then you can make many an argument against TDD. But XP as a development methodology is build-up by many levels of feedback loops (communication), which TDD is one of. Each of these feedback loops (practices) complementing each other to deliver a stunningly better result in software projects than Traditional methods (Waterfall).

On a separate note, when doing TDD and writing the test first. You are stating the problem first, then the state the solution second. In general you don’t make a mistake twice.

The other interesting aspect of TDD is, as soon as you are comfortable with the TDD method of writing code. You suddenly realize that the design of your objects and components change. Your objects display better object-oriented characteristics.

In Traditional Software projects, programmers write the code and then the tester gets the software and does the testing. This time gap also means you have this disconnect between creating, finding and fixing the bugs in the code.

The other common managerial practices when the budget gets tight, is to cut some testing time. TDD tries to overcome this problem as well.

There are many more reasons I can give why TDD is good for any software development effort. In my opinion it helps you to write Quality code.

Technorati Tags:

powered by performancing firefox

Posted in TDD | 2 Comments »

Specifications are useless

Posted by Marcus Wyatt on 5 August 2006

Jeff Atwood wrote:

I finally understand what Linus Torvalds was complaining about:

A “spec” is close to useless. I have never seen a spec that was both big enough to be useful and accurate. And I have seen lots of total crap work that was based on specs. It’s the single worst way to write software, because it by definition means that the software was written to match theory, not reality.

Specs, if they’re well-written, can be useful. But they probably won’t be. The best functional spec you’ll ever have is the behavior of real applications.

Could not have agreed more.

I’ve seen many a Functional Specification that is just a total waste of paper. Missing the important stuff like business rules and how the client business actually works. I think that if you aren’t able to have an onsite customer, then you would be better off using techniques like use-cases and fit story tests to capture the essential business behavior.

To build the best possible software, you need to have constant communication and refinement of the software by engaging the client continuously. This I’ve found is still the best method for building software. You have a customer team writing stories about what they want to system to do and the developers implement the stories in a consultative style together with the Customer.

The other interesting social change using this method of building software is that the Customer and Development Team suddenly start to collaborate. In my experience I’ve found that in traditional software development, the Customer are trying to get the most value from the development team and the development team wants to cut as much functionality as possible. This normally causes the parties to concentrate on contract negotiation and not on building the best software for the problem. I like to use the analogy of the Rugby Scrum, rather than scrumming against each other, in other words pushing against each other, lets rather Scrum together (push together) to achieve a spectacularly better result.

Technorati Tags:

powered by performancing firefox

Posted in Communication, Development | Leave a Comment »

The focus for the project implementation

Posted by Marcus Wyatt on 5 August 2006

Following on from my discussion of Specifications are useless, I’ve read a post by Patrick Kua regarding “Planning IT projects”. He makes some really interesting comments which I agree with:

An alternative I propose is a lighter weight approach with businesses focusing on what they want to do and not what projects a particular group within the business proposes. It’s more important to focus on the business problem first and the implementation details last so that both are aligned as closely as possible. After identifying what the business want to do they should next define how much they would like to spend. The amount needs to be feasible and measuring existing project costs and benefits and getting IT involvement is definitely required. Magic numbers plucked from thin air are never useful but do need to be balanced in terms of value maximisation and technical feasibility.

The focus for the project implementation should also be different from traditional methods. The focus should no longer be ‘keep to the plan’. It should instead maximise the value the business gets while keeping aligned with the business objective. Agile projects provide a great way of doing this by splitting down the detail into chunks that have identifiable value, getting the business to continually identify what is valuable in relation to their business objective and then getting the value faster and earlier than a big bang approach.

Technorati Tags:

powered by performancing firefox

Posted in Development | Leave a Comment »