exceptionz

Thoughts on Technology, Methodology and Programming.

Archive for the ‘TDD’ Category

You can now build the source code in either VS2k5 or VS2k8

Posted by Marcus Wyatt on 11 March 2008

I’ve updated the source code to include some conditional compilation directives to support different Visual Studio IDE versions. So if you are still stuck in VS2005 land, you can now build the source and be able to take advantage of the new features that Owen Evans added.

These include the new attributes (Context, BeforeAll, BeforeEach, AfterAll, AfterEach) and new functionality like Collection.Contains#WithProperty. If you lucky to be using VS2008 you’ll have new functionality that allows you to pass lambda’s. For more information look at http://bgeek.net/2008/02/14/nspecify-rspec-well-closer-anyway/

Owen also added a new library called NSpecify.Framework.Extensions. This gives you some extension methods that you can use to specify your expectations directly on the object under test.

i.e. newDeveloper.Surname.Must().Equal(“Evans”);

Nice hey!

Posted in BDD, Development, OO, Software, TDD, Tools | Tagged: , , | Leave a Comment »

Links for 31 October 2007 (Ruby, Rails, Rails Plugins, RSpec, RBehave, CSS, JavaScript)

Posted by Marcus Wyatt on 31 October 2007

Ruby

Rails

Rials plugins

RSpec & RBehave

CSS

JavaScript

Technorati Tags: , , , , , ,

Powered by ScribeFire.

Posted in BDD, CSS, JavaScript, Rails Plugins, RoR, TDD | Leave a Comment »

Introduce Behavior-Driven Development without much resistance…

Posted by Marcus Wyatt on 17 September 2007

Within the .NET community the idea of test-driven development is starting to become common knowledge. This doesn’t necessarily mean that it is practiced. I believe that although many people find the idea of TDD very easy to grok, they find the implementation of TDD very hard and many revert back to their old ways of working soon after trying TDD.

So why is TDD so hard?

I don’t think that it is only one aspect that makes TDD hard, but a culmination of many factors together. Firstly, you should have a good understanding of OO. You need to understand how to de-couple your objects. How to isolate the class under test by mocking or stubbing the external dependencies. If you are one of those developers that write huge methods with multiple lines of code, then I’m afraid you are not going to be able to practice TDD.

There is also old habits. It is hard to kick old habits, like I can profess when I stopped smoking a couple of years ago. But with perseverance you can loose those old habits.

The other problem is of course the vocabulary you use during a TDD session. All the words you work with has their grounding in validation. i.e. Test, TestFixture, Assert, etc. This makes it quite hard to focus your attention on what you are really doing, specifying the functionality (behavior) of the object. It’s quite simple to see that if I talk about writing a test for the Order object and I assert that the order should be filled, that the language I use isn’t very helpful in making me think about the behavior of the Order. But if I’m writing a specification for the order to specify that an order can be filled, then suddenly my language doesn’t create a barrier.

So what do you mean by ‘introduce BDD without much resistance’?

Wel, in .NET you have the ability to alias and that ability is what I’m using to create an easy why to change the nomenclature of your code. Here is a example of what I’m talking about:

 

    3 using NSpecify.Framework;

    4

    5 using Rhino.Mocks;

    6

    7 using SetupResources = NUnit.Framework.SetUpAttribute;

    8 using DestroyResources = NUnit.Framework.TearDownAttribute;

    9 using Functionality = NUnit.Framework.TestFixtureAttribute;

   10 using Specification = NUnit.Framework.TestAttribute;

   11

   12 [Functionality(Description=“Describe the functionality of the order domain object.”)]

   13 public class OrderFunctionality

   14 {

   15     private MockRepository mockery;

   16     private IWarehouse warehouse;

   17

   18     [SetupResources]

   19     public void BeforeSpecificationExecute()

   20     {

   21         mockery = new MockRepository();

   22

   23         // setup the warehouse mock

   24         warehouse = mockery.CreateMock<IWarehouse>();

   25     }

   26

   27     [DestroyResources]

   28     public void AfterSpecificationExecuted()

   29     {

   30         mockery.VerifyAll();

   31     }

   32

   33     [Specification(Description=“Should not be able to fulfill order.”)]

   34     public void ShouldNotBeAbleToFulfillOrder()

   35     {

   36         string product = “Harry Potter and the Deathly Hollows”;

   37

   38         Order order = new Order(product, 50);

   39

   40         mockery.Record();

   41

   42         Expect.Call(warehouse.GetInventory(product)).Return(10);

   43

   44         mockery.ReplayAll();

   45

   46         order.Fill(warehouse);

   47

   48         Specify.That(order.IsFilled).Must.Equals(false);

   49     }

   50     [Specification(Description = “Should be able to fulfill order successful.”)]

   51     public void ShouldBeAbleToFulfillOrder()

   52     {

   53         string product = “Harry Potter and the Order of the Phoenix”;

   54

   55         Order order = new Order(product, 50);

   56

   57         mockery.Record();

   58

   59         Expect.Call(warehouse.GetInventory(product)).Return(61);

   60

   61         mockery.ReplayAll();

   62

   63         order.Fill(warehouse);

   64

   65         Specify.That(order.IsFilled).Must.Equals(false);

   66     }

   67 }

As you can see from reading the code snippet above, by using aliasing we are able to change the language we use. The cool thing about aliasing the NUnit attributes, is that your current build script or the tools you use to run your tests would still work effortlessly. But, now we are reading and thinking in terms of specifications and not tests. Cool Hey!

If you are wondering how I’m able to write Specify.That then you should check out NSpecify.

Technorati Tags: ,

Powered by ScribeFire.

Posted in BDD, Development, OO, TDD | 1 Comment »

ReSharper UnitTestSupport Add-in for NSpecify

Posted by Marcus Wyatt on 20 April 2007

t: I’ve never posted the link to the download, you can find it below or here.

Edit: I would suggest you rather grab a copy of the source using Subversion or Git (If you’ve been adventurous) and build the library yourself. The source supports both VS2K5 & VS2K8, so if your version of VS is 2K8, you can take advantage of the new language extension method features. If not, you’ll be able to do the plain old vanilla spec’s.

Here is the svn command:

svn co http://nspecify.svn.sourceforge.net/svnroot/nspecify nspecify

via the command line. If you are using TortoiseSVN just create a directory somewhere and use this

http://nspecify.svn.sourceforge.net/svnroot/nspecify

url in TortoiseSVN to pull down the source.

Once you’ve compiled the assemblies, you just need to copy the following

  • JetBrains.ReSharper.PowerToys.NSpecify.dll
  • JetBrains.ReSharper.PowerToys.NSpecify.xml

assemblies to the this directory:

C:\Program Files\JetBrains\ReSharper\v4.0\v.Everything\Bin\Plugins\NSpecify

If the Plugins and NSpecify directories don’t exist, create them.

————————————————————————

The NSpecify Unit test support plug-in for resharper will give you the ability to run your NSpecify specification with the ReSharper UnitRun 1.0 or ReSharper for Visual Studio 2005.

Next to declarations of test classes and single tests, ReSharper adds special icons on the left gutter of the editor window. Click these icons to run or debug tests. You can also run tests for a whole solution or project from the Visual Studio’s Solution Explorer. Just right-click the project or solution and select run or debug tests.

When you start running unit tests, ReSharper opens the Unit Test Runner window that is intended to help you with analyzing test results. Using this window, you can also run/re-run any tests. With Unit Test Runner , you can navigate from a failed test’s output to the lines that originated the exception, all with a single click.

Here is the Installation instructions:

  1. Close Visual Studio 2005.
  2. Extract the contents of archive, including the NSpecify folder, to: %ProgramFiles%\JetBrains\ReSharper\VS2005\Plugins
  3. Launch Visual Studio 2005.
  4. Open a project containing NSpecify specs.
  5. Open a spec’s file containing a functionality with Specifications. Standard ReSharper icons will appear in the left margin and allow you to run the specifications.

Known Issues – via James Kovacs

  • ReSharper Unit Test Runner icons do not appear beside Functionality Fixture and Specification Methods.
    ——————————————————————————————————-
    This is typically caused by having an assembly reference to another unit test framework. ReSharper Unit Test Runner (and UnitRun) only support a single unit test framework per test assembly. Remove references to other test frameworks from the References in your spec project. This is a known limitation in the JetBrains’ current unit test runner implementation. A plugin votes on whether the current assembly contains tests that it can run. If the plugin votes “yes”, the unit test runner stops querying additional plugins. NUnit and csUnit get queried before third-party plugins.

For additional ReSharper test plug-in:

Posted in BDD, Development, Software, TDD | 10 Comments »

NUnit addin for NSpecify

Posted by Marcus Wyatt on 19 April 2007

I’ve completed the NUnit addin and you can now download the addin and run your NSpecify specs from within the NUnit Gui or command line. Download the assemblies here.

To install do the following:
1. Unzip the assemblies to the %NUnit_Install_Directory%\bin\addins
2. You’re done!
3. Enjoy!!

Note: This addin will only work with NUnit v2.4.0.0 or higher.

Technorati Tags: , ,

Powered by ScribeFire.

Posted in BDD, Development, Software, TDD | Leave a Comment »

NSpecify.Framwork Beta 1 release

Posted by Marcus Wyatt on 19 April 2007

I have a new version of the NSpecify framework ready for download. With beta 1 release I have completely removed any references to the NUnit libraries and completed some of the specifications that was still outstanding. At the moment I’m working on a Resharper, TestDriven.NET and NUnit plug-ins.

The download for the framework is here and you can find more information about NSpedify here.

Enjoy….

Technorati Tags: , ,

Powered by ScribeFire.

Posted in BDD, Development, TDD | Leave a Comment »

RSpec specifications in C#

Posted by Marcus Wyatt on 13 September 2006

Scott Bellware posted a very interesting article around using C# 3.0  Extension Method to create the same effect as Ruby Mixin to extend existing objects with new methods.

Basically, what I’m talking about is the ability to add a method to an object within a specific context without accessing the sourcecode. For example, add a ToCamelCase() method to the string object in .NET.

This may sound like a bit of voodoo and for someone who’s only ever coded in an strongly typed language, it will definably look that way. But dynamic languages like Ruby and Small talk has always had this behavior.

“Enough rambling man, show us some code”

Here is some of Scott’s examples:

NSpec in C# 2.0 NSpec in C# 3.0 with NSpec.Extensions
Specify.That(actual).ShouldEqual(expected) actual.ShouldEqual(expected)
Specify.That(actual).ShouldBeTheSameAs(expected) actual.ShouldBeTheSameAs(expected)
Specify.That(actual).ShouldNotBeTheSameAs(expected) actual.ShouldNotBeTheSameAs(expected)
Specify.That(value).ShouldBeTrue() value.ShouldBeTrue()
Specify.That(value).ShouldBeFalse() value.ShouldBeFalse()
Specify.ThrownBy(method) method.ThrownBy()
Specify.That(actual).ShouldBeOfType(expectedType) actual.ShouldBeOfType(expectedType)

Here’s Scott’s example of an NSpec specification written in C# 3.0 that used the extension methods. 

using NSpec.Framework;
 
// Import extension methods for NSpec
using NSpec.Extensions;
 
namespace Examples
{
    [Context]
    public class ExampleContext
    {
        [Specification]
        public void A_string_should_equal_another_string_when_both_strings_have_the_same_value()
        {
            string s = "foo";
 
            "foo".ShouldEqual(s);
        }
    }
}

This is really cool, because now you can write your expectations naturally on the object or property that you want to validate.

tags: , , , ,

Currently listening to: Winamp *** 434. atb – drum n bass and beyond – prime

Posted in BDD, Development, TDD | 5 Comments »

Great BDD and rSpec Tutorial

Posted by Marcus Wyatt on 1 September 2006

Luke Redpath posted a great rSpec and Behavior-Driven Development tutorial that is one of the best I’ve read in awhile.

 

tags: , , ,

Currently listening to: DJ River / VA – DJ River – The Resolver (Winter 2006) [DJRiver.com]

Posted in BDD, RoR, TDD | Leave a Comment »

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 »