Coding and Dismantling Stuff

Don't thank me, it's what I do.

About the author

Russell is a .Net developer based in Lancashire in the UK.  His day job is as a C# developer for the UK's largest online white-goods retailer, DRL Limited.

His weekend job entails alternately demolishing and constructing various bits of his home, much to the distress of his fiance Kelly, 3-year-old daughter Amelie, and menagerie of pets.

TextBox

  1. Fix dodgy keywords Google is scraping from my blog
  2. Complete migration of NHaml from Google Code to GitHub
  3. ReTelnet Mock Telnet Server à la Jetty
  4. Learn to use Git
  5. Complete beta release FHEMDotNet
  6. Publish FHEMDotNet on Google Code
  7. Learn NancyFX library
  8. Pull RussPAll/NHaml into NHaml/NHaml
  9. Open Source Blackberry Twitter app
  10. Other stuff

Fhem DotNet - Let's Try That Again

Hi all,

I have a confession to make - my initial efforts to create a .Net FHEM front end have become mired in the deepest depths of geek porn - I've spent the last 2 months building the coolest (but mostly pointless) Fhem <-> POCO (Plain Ol' Code Object) mapper à la Fluent nHibernate, using all sorts of stuff I'd not really dug into before, such as generics, consuming lambda expressions, Moq-based isolation testing, fluent APIs, etc.

But so far, as much fun as it's been, I've got squat to show for it.  I'm as annoyed as anyone, I've been boasting about having this nifty central heating control thing, and when anyone asks about it up comes a Putty console, and suddenly it all seems just lame.  Plus it's pretty clear that at this rate, as soon as I have anything useful out the door, I'll be basking in a freak British summer heatwave, with central heating concerns a distant memory.

I've decided the way forward is to start with a clean slate and what I hope to be a cleaner methodology.

Behaviour Driven Development = A Kick in the Arse

So on to what's prompted this post.  Recently I've had an encounter with a work colleague that's provoked me to have a rethink - I've just come across the concept of BDD (Behaviour Driven Development), particularly using the SpecFlow framework, and I'm really, really excited by it.  So I've decided to take the code I've got to date, tear it down (it's just way over-complicated to be fit for purpose now), and have a go at rebuilding using BDD methodology.

Now I know it's risky to produce my first open source app using something I'm not experienced with, so I'm pretty sure it'll actually turn out BDD-lite, and there are still a lot of questions I've got around things such as where classic unit tests and TDD fits into this picture, but there's tons of material out there around BDD, and I think if I miss this chance to start this project again as I want to go on, I'm going to regret it.

Apparent Benefits of BDD

As stated above, I'm currently VERY new to BDD (actually only a couple of days of seriously looking at it), but straight away I can see the following benefits:

  1. Since tests are tied to real-world usage of a component, there's less chance of getting stuck coding things that don't deliver real-world behaviour (e.g. premature optimisations, unnecessary levels of abstraction, etc)
  2. The simple statements that make up SpecFlow features can have quite substantial chunks of C# behind them, and they are inherently reusable, unlike in TDD where there's often a temptation to copy-and-paste tests
  3. Since tests have a plain-English abstraction on them, they can be less brittle (although see this blog post by Dan North for more on this).

What happens next?  Well hopefully I'll be able to extract enough from my existing solution to quickly get something of a minimal web front end together, and I'll get it up on the Google Project site.

References

These links weren't strictly used to write this post, but they're the starting points that helped get me started.

Have good evening all,

Russ


Permalink | Comments (0)

Add comment

  Country flag

biuquote
  • Comment
  • Preview
Loading