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:
- 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)
- 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
- 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.
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,
If you enjoyed this post, make sure you subscribe to my RSS feed!