Behavior Driven Development Root Cause Analysis
A (not-so) long time ago, when the world was young and ASP.NET web components were cool, my colleagues pushed me into unit testing in with NUnit and jsUnit. When I switched to ruby, Test::Unit made me feel right at home with the familiar syntax and assertion syntax.
Until recently I slipped in webrat as a selenium abstraction in my rails integration tests, while trying to battle the constant slippery of client-side errors the project was experiencing.
One thing lead to another, and soon I replaced the built-in integration tests with cucumber, and removed the tests of a simple gem in favor of specs. Before you know it, I was purchasing the beta of the rspec book, reading about the strange and sometimes awkward syntax of my new tools.
From a programmer’s perspective it was not that different than the xUnit frameworks I knew. Sure, things were called differently, I was “shoulding” and not asserting, and the MVC concerns were split in a slightly different way. A matter of taste, I was thinking, not a big deal. Keeping an eye on twitter, many people were stating the same. I was not really paying attention to the native language descriptions I was acked to provide, considering them redundant at best.
It actually “hit” me when I was reading my next purchacse, The art of agile development. I was doing it wrong. Well, not really wrong, but rather missing the point. I was doing TDD with the BDD tools.
So what is the real difference?
wikipedia nails it:
Behavior Driven Development (or BDD) is an Agile software development technique that encourages collaboration between developers, QA and non-technical or business participants in a software project. It was originally conceived in 2003 by Dan North as a response to Test Driven Development, and has evolved over the last few years.
BDD, while carrying all the benefits of TDD has certain (less than) subtle differences. It is far more aligned with the Agile values, and extends the concept of testing to force developers in actually communicating with them customers. With TDD, you aim at verifying that your code actually works. With BDD, you are communicating with the rest of the team, providing human readable artifacts, which document the logic of your implementation.
It took me a while to figure out this. BDD is not about the tools, it is about the process. The sole usage of RSpec, Cucumber or any other BDD framework out there does not make you behavior driven. It is all about the communication, which the agile evangelists love to brag about. And I consider it a bold attempt to resolve one of the most complex problems in our industry – project failures due to failed communication.
Okay then, let’s do it! All the cool kids are doing it, right? OK, I am installing cucumber…
Hold your horses. Let’s figure if you really need it. Remember: To go for behaviour driven development model, you should first qualify for the test-driven one. But is it so? And why TDD is not mainstream? Why don’t we study it in the universities?
The often overlooked fact is that many companies and teams don’t care about stability and lack of bugs. In many cases, rightfully so, since this is not going to make the software successful. We all know examples where buggy, slow software dominates the market because of good marketing and sales, or because of the brilliant idea it implements. Or just because of pure luck. This is pretty common, in fact. Maybe it applies to you too? Maybe you are working as a “bolt” in a company developing enterprise product, where the sales decisions are made by exectutives puffing fat cigars driven by commission rate contracts. And maybe the main business model is based on charging dearly for bugfixes and consulting fees? If this is so, you can safely ignore this article. You should not try to improve the quality of your work, anyway.
Adopting BDD is even harder. It faces the problems of its predecessor along with the obstacles that prevent Agile from becoming mainstream. What BDD has to do with Agile? A lot. Actually, BDD makes sense only in Agile environment.
The Agile Problem
Many people perceive Agile as yet another “methodology”. Nothing can be further from the truth, actually. Agile is just a term that wraps a set of values, that the team shares. If your team shares them, the practices such as XP, Scrum and so on come naturally, because they are just tools for reaching the goals that matter. Without that, XP is a torture, and scrum is just one huge masquarade, where people pretend to listen to each others yada-yadas.
Of course, agile is a buzzword nowadays. It is interesting to figure out how many of the employees in the companies who proclaim themselves agile have actually read this:
The Agile Manifesto
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a planThat is, while there is value in the things on the right, we value the things on the left more.
A hidden message that has long evaded me here – the first line in the manifesto is a value itself. A person with an “Agile” mindset proactively searches for better ways of developing software.
Unfortunately, the Agile manifesto has a problem with many software producers’ personal values. Try it for yourself – answer honestly what best describes your motivation for doing software. Maybe
- You are a sociopath and you hate dealing with people. Being a programmer gives you the freedom not to interact with them nasty human beings on a daily basis;
- Or you are all for the money, and there is nothing that can put more cash on the table;
- Or you have always wanted to be a famous artist/rockstar, but failed at playing the guitar;
- Or It just happened, while you were wondering what to do with your life;
- Or maybe you consider yourself a brainiac, seeking to resolve complex problems?
None of the above is that bad in fact, we are all humans. But if these are the reasons for you doing software, then your personal values are in a direct conflict with the agile mindset where working software, collaborating with customers and interacting with the individuals should be the main motivation.
In the context of BDD, any attempts to adopt it without first making sure that the agile mindset is clearly present in your team does not make much sense. Sure, you can write specs, and elaborate cucumber features – but this won’t be more than a fancier TDD (or, best case, a single person BDD – not that bad as an excercise!). BDD really shines when it comes to team collaboration efforts.
Well, but how exactly does BDD will help me communicate with the rest of the team?
By forcing you to speak their language, and by keeping you focused on resolving the problems that matter instead of floating away in activies that have no business value for the project. As Ryan Bates says
Even though I’m a developer, I still like writing Cucumber stories (instead of Ruby) because it helps me put on the Customer hat.
Unfortunately, the technical aspect of bringing the natural language definitions to the rest of the team is left as an excercise to the reader. I would like to give you a suggestion – use Continuous Integration. You have one, right? It will constantly update and visualise the business cases you’re working on, the ones that are being resolved, what is pending, what is broken, and what is in progress – either by emails or by generated web reports. Given that, the rest of the team should be able to easily check what are you doing currently, and how’s it going.
But, the customers/managers won’t bother reading my crap!
Perfectly valid point, especially valid for non-agile teams. Unfortunately there are two, sometimes overlapping reasons for that.
First of all, them business people are too busy. Oh yes, they are. But if they are too busy to pay attention to the project they payed money for, then it is obviously a project that should not have been started in the first place. You need a domain expert to verify your work, and you need a stakeholder to be up-to date and to make decisions on priorities and release schedule.
Second problem is that specs are too techincal, and often do not make any sense to non-developer. Guess what? You are the one that provided sloppy natural language descriptions. And I do feel your pain at this point, because us developers historically suck badly at explaining our actions. You should not give up on this though. Read the output of the spec results with the rest of the team. Ask for feedback frequently; what makes sense? is the explanation too vague? Aren’t the specs for some internal code parts too “technical”? Hard to understand specs may be sign that your design differs from the domain.
“The Revolution Will Not Be Televised”. And BDD won’t be mainstream.
A BDD is a practice that makes sense in the right environment. Remember that the agile environment relies heavily on each individual personal virtues, and agile teams are hard to find, build and maintain. And forcing agile is not known to work.
swfaddress rails sample – my modest contribution to an open source project
My friend Rostislav (Asual) managed to release SWFAddress 2.2 for Christmas (and even before this, have you heard of a release that made it before the planned deadline?). A brand new rails 2.2 restful example produced by yours truly was included in this release.
I can’t really remember how I got into this – I think that he asked for some obscure PHP detail on the SEO sample. Having a lot of boring work to do, I quickly managed to find an excuse to get away from it. The first example was quite clunky, made no use of the rails routing, had some quirky “datasource” views, and used if/else to provide conent for the different urls. Less then an year ago, I am finally capable of doing it “right” 
.
Check the code in sourceforge – I also included a small capistrano deployment script for the setup on a linode VPS. This also happened to be my first encounter with Passenger and REE – and boy, was the setup smooth? Dealing with monits, nginxes and thins can sometimes make your head spin.
Writing with style – in textile
Disclaimer: This is not a comprehensive guide, and it did not involve in-depth research for solutions of the problems I am describing. It is more like fun DIY stuff I did to kill some time and learn more about vim, ruby, bash and textile. I am not bashing anyone from WordPress about their decisions – big props to the guys (especially Niki) for making sites like I can has cheezburger possible.
Prolonged exposure to the 37signals’ products Basecamp and Campfire made me a textile addict. Textile is very natural for mind flow, and allows me toMy search for textile plugins for WordPress was quite unsuccessful – some half-baked solutions which for some reasons did not work for me. concentrate on what I want to say, while taking care of the mundane html details.
However, I am bound to WordPress installations for all of my current content publishing places. I used textpattern for a while before, but at some point the convenience of the hosted WordPress blog and my lazyness turned out to be more important.
My search for textile plugins for WordPress was quite unsuccessful – some half-baked solutions which for some reasons did not work for me.
On top of this, the WordPress writing mode leaves a lot to be desired. I can’t stand wiziwig (no, won’t bother to write it properly). The html editor does not have fullscreen mode. On top of this, I am vim addict, and writing in anything else for long time is a pain in the right wrist.
Another thing that really bothers me in WordPress is the lack of revision history. Of course, re-implementing source control in a blog engine would not be the wisest thing to do. I believe that this is why some bloggers started using Github as blogging engine. When you’re a programmer, this looks completely natural, right? Well, let’s find a solution for these.
How to use textile – the programmer’s way
First things first, let’s move writing back to the desktop. I am a huge proponent of using web based applications whenever possible, but in this case I will stand on the opposite side. I need a full-screen, feature-rich environment, which allows me to concentrate on the writing. Actually, writing is much like coding. Hm, let’s try the same approach, shall we? For coding, I use vim + screen + gnome-terminal on full-screen mode. This gives me huge amount of whitespace(or, should I say, blackspace?), while hiding the clutter of the OS menus.
Terminal screenshot
Hm, not really. When you write code, you need to see a lot at every moment. For the content, this is not that essential. In fact I would love the opportunity to enjoy the beautiful Consolas font in large size Yep, I must confess I use vista fonts on Ubuntu.
Let’s zoom a bit then (^+, can zoom out with ^-). Should love these features of the terminal. Much better.
Terminal screenshot - large font
Inspirational. We’re set.
Textile highlighting (why not?)
A simple google search for vim and textile provides great results, so I won’t bother discussing this at all.
The hard part – sending textile to WordPress
As said earlier, textile and WordPress do not like each other. I could go for writing plugin myself, but PHP is not something I would like to dig into right now. Let’s do it with ruby, then.
From this point, all you have to do is grab the source from the generated html file (this could be automated from vim using xclip) and paste it in the WordPress text field.
Source controlling your blog posts.
I am already using git for work and for fun (besides, subversion repository would be an overkill). In fact, I really don’t need my content stored somewhere on a public space – too shy to share the drafts anyway. Let’s just store it locally, then.
cd ~/Documents && git init git add blogging-with-textile.textile git commit -m "first draft"
Bonus tip – spell check your blog post in vim.
Don’t tell me that you don’t use the spell checking feature of vim. You don’t? Well, I did not use it too, till recently, but it is quite handy. Spend some time in the :help spell section, for mastering the art of spell-checking in vim. It is worth it.
Using monit to manage backgroundrb
Somehow these days I had to deal with long running tasks in my rails projects. By far, BackgrounDRb seems like the right tool for the job. However, some gotchas gave me one of those typical sleepless nights trying to figure out how to deploy the damn thing.
Enter monit
The production environment I set up includes nginx, and monit with 4 thin instances, running on ubuntu server. Not being a professional sysadmin, I had some troubles with mongrel clusters. Besides, thin seems to work better for my case. Inserting BackgrounDRb in the game seemed like a trivial task. Like, monit is meant to do that?
Google first, than think
Trying not to be a smartass, I did some searches for monit configuration, stumbling upon Capitate, which seemed like the right thing to use. Wrong. I tried
cap backgroundrb:monit:install
Which indeed installed a monit file that may work on fedora or other systems, which have /sbin/service. Ubuntu does not. So I reluctantly tried to create my own config. How hard can it be?
check process backgroundrb
with pidfile /var/www/apps/myapp/shared/pids/backgroundrb_11006.pid
start program = "/usr/local/bin/ruby /var/www/apps/myapp/current/script/backgroundrb start
-e production > /var/www/apps/myapp/current/log/backgroundrb-cap.log 2>&1"
stop program = "/usr/local/bin/ruby /var/www/apps/myapp/current/script/backgroundrb stop"
group myapp
Let’s not get too fancy with restarts and so on, I am not sure what are the typical resources it needs. Let’s reboot, and check what goes on. 4 ruby processes running, no sign of BackgrounDRb.
cd /var/www/apps/myapp/current/log && less log/backgroundrb_debug_11006.log
Hm, some vague error about No such file or directory – packet_worker_runner. This result pointed me to the right direction – although the executable was available, Monit somehow did not see it. Of course, there is a good reason to do so – security. Say no more:
For security reasons monit purges the environment and only set a
spartan PATH variable that contains /bin, /usr/bin, /sbin and
/usr/sbin. If your program or script dies, the reason could be
that it expects certain environment variables or to find certain
programs via the PATH. If this is the case you should set the
environment variables you need directly in the start or stop
script called by monit.
No sign of /usr/local/bin, where the packet_worker_runner is situated (installed ruby from source). Fortunately the FAQ entry was a helpful, and adding this line at the top of script/backgroundrb file solved my troubles:
ENV['PATH'] = "#{ENV['PATH']}:/usr/local/bin"
The good news: I did not have to do anything about my cap recipe, since I already restarted monit with the group of my add. Grabbed a beer from the fridge.
