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.
@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);
}
}
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);
}
}
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
...
}
}
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);
}
}
Recently there has been much talk of the perceived deficiencies in JUnit. Much of this discussion has focused on the implementation issues of JUnit, but none of them have actually addressed if JUnit (or a rewrite of JUnit) is actually suited to one of the main areas it is being used in, namely in Test/Specification Driven Design. As I “mentioned before(magpiebrain – It’s time to drop the ‘T’ from TDD)”:http://www.magpiebrain.com/archives/2004/07/05/tdd, the constant reference to the word ‘test’ can lead to a misunderstanding of what TDD actually is – one proposed solution was to drop the word ‘test’ altogether. Others are looking at writing tools which can more closely match what we are trying to achieve with test/specification driven design.
As part of my month long period helping run London’s “Geek Night”:http://geeknight.thoughtworks.com/index.php/GeekNight, we’ll be having a presentation of JBehave, which is being written as a JUnit replacement. Rather than simply attempting to reproduce method call for method call what JUnit does, it is changing the language used in an effort to help change the developers mindset, whilst at the same time improving support for other specification techniques such as mock objects. Personally, I’ve yet to actually see the thing running, so I’m hoping the demo will at least be informative! “Nat Pryce(Mistaeks I Hav Made)”:http://nat.truemesh.com/ is also threatening to demo his latest project, although I still don’t fully understand it so it’s best to come along and see for yourself…
_[Update 11:44, 19/07/2004]_ : Nat sent this along to explain what his tool does:
It’s a way of specifying “tell don’t ask” object-oriented code that addresses some of the limitations of mock objects and can be used to generate useful documentation.
If you want to pop along and see if it’s any good, make comments, heckle, throw rotten fruit or whatever, just pop along to the “Geek Night Wiki(Geek Night London 21 July 2004)”:http://geeknight.thoughtworks.com/index.php/GeekNightLondon21July2004 and put your name down. Any questions (like how to get there), feel free to “drop me a line”:http://www.magpiebrain.com/contact.
By no means am I an AOP expert, but the claims made by a recent “devx article”:http://www.devx.com/Java/Article/21463 (spotted thanks to “John Flinchbaugh(Dynamic Proxies)”:http://www.hjsoft.com/blog/showArticle.java?id=223 ). Entitled “Java Dynamic Proxies: One Step from Aspect-oriented Programming” made me want to comment. It claims that:
…once you understand proxies, you’ve made a small conceptual leap towards the bigger picture—aspect-oriented programming (AOP)
Firstly, dynamic proxies, have nothng to do with AOP. Sure, they can be used to accomplish some AOP goals in the way they allow code to be dynamically wrapped around methods, but they are a means to an end. AspectJ doesn’t even use dynamic proxies – it inserts Aspects using compile-time sourcecode manipulation. The use of dynamic proxies in AOP is an implementation detail, not something inherent in the use of AOP.
You might gain some understanding as to how some of the AOP frameworks implement Aspects by learning about dynamic proxies, and you might even get a good feeling of the power provided by dynamically inserting code, but you are a long way from fully understanding the complexities of AOP.
Courtesy of Warren Ellis, via his blog “Die Puny Humans(Die Puny Humans – not work safe)”:http://www.diepunyhumans.com/ (in no way safe for work!):
“sure, buy yourself a cute little Apple. Then save yourself some time and money by throwing the fucking thing out of the window, going out again and getting yourself a proper bloody computer”
magpiebrain 