RSS
Facebook
Twitter

Thursday, September 30, 2010

Two podcasts about unit testing

I listen to podcasts all of the time, I don’t listen to them in any specific order - I just download the new podcasts and choose one in random. From time to time it looks as if I have some pattern in my listening preferences but it’s purely coincidental.

Last week without intending to I found myself hearing two podcasts about unit testing (more or less).

Talking Shop Down Under: Episode 26 - NSubstitute

In case you haven’t heard this podcast before you probably should. In episode 26 they talk with Anthony Egerton and Anonymous Dave about NSubstitute – a new Mocking (Isolation) framework. As you might have expected NSubstitute is the topic of the podcast but they also talk about fake objects and unit testing in .NET.

NSubstitute is an Isolation framework similar to Moq and Rhino.Mocks it has a AAA (Arrange Act Assert) API and it doesn’t have the distinction between mocks and stubs (finally someone has seen the light). If you’re interested in more information have a look Mocking Comparison in Richard Banks blog.

Software Engineering Radio: Episode 167: The History of JUnit and the Future of Testing with Kent Beck

I’ve been listening to SE-Radio for a few years now and it’s one of my favorites. This interview with Kent Beck is one of their best shows yet – bring the guy responsible for TDD and Extreme programming, put a microphone in front of him and you can’t go wrong.

Kent talks about Agile, unit testing, JUnit and the state of software development. If you’re a software developer and you take your work seriously – you must hear this podcast.

One last thing

A while ago Kent Beck visited Typemock and recorded an episode of Typemock TV – if you want check it out if you want to learn more from the guy that helped change the art of software developer.



Monday, September 27, 2010

Book review: DSLs in Boo: Domain-Specific Languages in .NET

For most .NET developers XML files are the sole means of enabling users to extend their application, why mot - it’s a “human readable” extendible format - after reading this book I know better…

in DSLs in BOO Oren Eini a.k.a Ayende Rahien (or is it the other way around) explains what are DSLs (Domain specific Languages) and shows how to easily build one using the BOO and plain old .NET.image 

This book is an easy read and overall makes the subject of creating a new language seems simple and easy – while reading this book I felt as if I was pair programming with the author.

The book starts with the all too familiar introduction to domain specific languages – but quickly gets down to business of creating new languages using BOO.

The author sets a good rhythm – each feature and use case are explained just enough so you won’t get overwhelmed with information but somehow manages not to get you bored.

As can be understood from its name this book is about creating DSLs using BOO programming language, this also means that  this book is about internal DSLs – languages created on top of existing languages and not creation of new fully functional programming languages – which is exactly what I need in my daily work. The examples in the book use RhinoDSL (also created by Ayende) to create the new languages and it has its own chapter (#7) that explains all about it.

The book can be divided into three parts –

  • Chapters 1 – 3: an introduction to domain specific languages with a brief explanation about DDD (Domain Driven Design), the BOO programming language and choosing which DSL type to implement (there are four)  by the end of the 3rd chapter you’ll be presented with your very first DSL.
  • Chapters 4 – 7:  Basic DSL creation and how to extend the BOO compiler. In this chapter you get to see how various syntaxes are possible using BOO extendibility and RhinoDSL.
  • Chapters 8 – 13: There is more to a new language than syntax – these chapters discuss how to test and document the newly created DSL as well as option for creating a UI for the new language. The last chapter act as a summery of the whole book showing how to implement a new DSL from the ground up with real world consideration.

I enjoyed reading DSLs in BOO, the minuet I’ve finished reading it I’ve used what I’ve learnt in my current project – how cool is that!



Tuesday, September 14, 2010

Don’t be pragmatic be agile

For those of you that didn’t know I used to work at Typemock. I was in the midst of the unit testing world where TDD (Test Driven Design) was my bread and butter. As part of my work I’ve learned, taught and blogged about unit testing and Isolation/Mocking.image

At Typemock I working in an “Isolated” environment where I always had time for writing tests, code reviews, and pair programming – and I believed that this is the way it should be done…

Since I left Typemock I was exposed to a new world – the world outside of the TDD inner circle where developers don’t write unit tests or write them after the code has been written.

Luckily for me my team were well aware of the benefits of writing automated tests even before I got there and so my main goal was teaching them how to improve their tests and how to use fake objects, but the change doesn’t happen overnight it does takes some time.

At Typemock I was very strict – the code should be written THE RIGHT WAY and pair programming should be done when possible, unit tests should be written before the code etc. On my current position I cannot afford to be this way – there is a big code base some of it written according to the best practices and some that did not, luckily for me most of the code is covered by automatic tests but some of them need to be refactored. Had I started my work expecting everything to be “perfect” I would have probably gone insane! Instead I’ve concentrated on incremental improvement, as long as I could see a daily improvement I was happy. I’ve used code reviews to teach coding practices and test writing skills, I’ve scheduled several sessions with the team and thought them about fakes and TDD and of course wrote quite a lot of code that served as examples for the rest of the team and helped me get familiar with the system.

 

Now when I look back at the last two months I see great improvement in the teams code and project quality.



Related Posts Plugin for WordPress, Blogger...