magpiebrain

Sam Newman's site, a Consultant at ThoughtWorks

Archive for ‘July, 2004’

I’m hoping to have another successful GeekNight tonight. It’ll be more development focused I expect – I’ll be working on a UI for JBehave (with a view to creating an IDEA plugin) and no-doubt others will be doing development they’d appreciate help with. If you fancy coming along, pop over to the wiki and “put your name down”:http://geeknight.thoughtworks.com/index.php/GeekNightLondon28July2004. More details can be found “here”:http://geeknight.thoughtworks.com/index.php/GeekNightLondon.

Advertisements

@PicoUnit@ has been developed with a view to reduce the amount of setup within specifications, using Picocontainer to instantiate and pass in the required dependencies. One use is to locate test data from an external source and pass it in (this example is showing PicoUnit working with JBehave):



class ProductCode {
  public final String productCode;
  public ProductCode(String productCode) {this.productCode = productCode;}
}

...

public class ProductTest implements picounit.Test {
  public void testProductHasNonZeroPrice(ProductCode productCode, Verify verify) {
    verify.that(new Product(productCode.productCode).getPrice() > 0);
  }
}

Continue reading…

Continuing a series of write-ups on the presentations made at “Geek Night”:http://geeknight.thoughtworks.com/index.php/GeekNightLondon last week, “Nat Pryce’s”:http://nat.truemesh.com/ latest project OO-Matron is next up.

Rather than the evolutionary approach of JBehave, OO-Matron might potentially be revolutionary, or might just be too complicated for people to use – I’m still undecided. It’s designed to replace existing Mocking API’s, whilst at the same time adding the ability to enforce system-wide invariants to your tests, which in turn can be used to provide system documentation.
Continue reading…

At last Wednesday’s “Geek Night in London”:http://geeknight.thoughtworks.com/index.php/GeekNightLondon, we had a presentation of three related software development projects. I’ll give a brief write-up of each of them, starting with “JBehave(Codehaus – JBehave)”:http://jbehave.codehaus.org/.

JBehave has been written as a replacement for JUnit, with a view for better suiting Test/Specification/Behaviour Driven Development (someone please write a book and rename this!). The first thing apparent from looking at JBehave, is the change in language:



public class TimerSpec {
    public void shouldMeasureAPeriodOfTime() throws Exception {
        // setup
        Timer timer = new Timer();
        timer.start();

        // execute
        // TODO make this not time-dependent - could possibly fail
        Thread.sleep(10);
        timer.stop();

        // verify
        Verify.that(timer.elapsedTimeMillis() > 0);
    }
}


Continue reading…

A pack of two Twinkies(R) has just landed on my desk. They’ll be my first. I’m thinking about hot-footing it over to a fish and chip shot and getting them deep fried…

I’ve been looking to simplify some exception handling code recently, namely I wanted to get rid of much of the defencive exception handling placed in event handlers in a Swing UI. Code like this:



public void actionPerformed(ActionEvent event) {
  try{
    //Do something
    ...
  }catch(Exception e){
    //handle exception
    ...
  }
}


Continue reading…

With the perceived desire nowadays amongst the unwashed (blogging) masses to simplify the way their code acquires dependencies (whether it be via setter or constructor or ego injection), a recent problem made me take a step back and look at the problem from a slightly different angle – before you start wondering about how to acquire your dependencies you should really be asking questions of yourself as to why you need those dependencies, and whether or not in your drive to simplify one piece of code you end up complicating the system as a whole.

Lets take the scenario I’ve been looking at recently. We have a @View@ object that represents a domain object. Next we have a @Viewer@ – this object is responsible for providing a display environment for the view. From time to time, a @View@ might need to display an error – this is something the @Viewer@ handles for it. Lets look at one approach to giving @View@ access to @Viewer@



public class MyView implements View {
  public void doSomething() {
    ...
    //Report error
    Viewer.instance().displayError(errorMsg);
  }
}


Continue reading…