[Code Friday] Tasty, tasty behaviour-driven development

[maradydd]

By way of sfllaw, a development paradigm I had not previously known about, and tool for developing in this fashion. Holy shmoley. I agree with Bill Tozier, I want this for Python yesterday.

Behaviour-driven development is basically test-driven development on steroids: it takes the principle we like to cite, "write your man pages first!", and hooks it right into the test-driven development cycle, except now you're developing one behaviour at a time, so you can write your tests piece by piece and have individual chunks of the system piece by piece. I like TDD, but sometimes I have to write code fast (and yes, TDD always ends up saving me time in the end, but we've all had those projects where OMG EVERYTHING IS ON FIRE AND THERE'S NOT TIME TO DO IT RIGHT. Behaviour-driven development eliminates your excuses to not do it right: you're producing code as discrete functional units, complete with tests to prove that they are correctly functioning functional units, and you're producing it fast enough to keep management/the client happy. (Clients are sometimes not happy when the first week of work goes into building the unit test suite. Yes, yes, I know, that week of work saves a month or more later on down the line. Some of my clients are no longer my clients for a reason.)

Behaviour-driven development is also a great tool for the "design the UI first" school of programming, and any project that doesn't follow that school of programming is doing it wrong. (Think of it this way: if you're writing a library, design the API first -- that is to say, write the man page first. If you're writing a web application, mock up the user interface, figure out what the damn thing's going to look like and do all your changing-your-mind about how the UI is going to behave before you start laying down AJAX requests.)

Also courtesy sfllaw, a talk by Ben Mabey explaining not only these ideas but the business decisions which motivate behaviour-driven development. This is a really great overview and I strongly encourage any programmer with a pragmatic spirit -- or, even better, an entrepreneurial one -- to block out half an hour of your time to watch it.

Alas and alack, Cucumber is not available for Python yet, and from what I've seen, I really like the way it works. It apparently can be used with PHP, but I really would prefer to avoid PHP if at all possible; my preferred style is just way too functional these days to blend well with PHP. (I've developed a thing for continuation-passing style in the last month or so.) This may end up being the thing that finally motivates me to learn Ruby. I have a little side project going on right now that has a web-application-framework-shaped hole in it, and I had been planning on using Django, but given that it's going to be a Javascript-heavy front end with likely a healthy dose of script.aculo.us, Rails could be a better tool for the job. I'll need to decide if I like how Rails talks to databases; I'm madly in love with the way Django does it and anything less will be a major disappointment, so this is definitely a factor to consider. (Current Rails devs, your input is welcome -- I know very little about your framework. I used to be cranky about the lack of integration with Apache, but there's mod_rails these days and I assume that removes a lot of the reasons I had for bitching.)

And I'd have real continuations. That's always a plus.

Decisions, decisions. But I do like the fact that tools like this exist at all; it's me who needs to get over my uncanny-valley problem with Ruby.

(karnythia, thewayoftheid, tanyad, I'm not talking about the project I'm doing for y'all, this is a different project. So many irons in the fire!)

Comments

[sfllaw.livejournal.com]

I am very happy with the way Django makes RESTful APIs easy. As such, it is JavaScript-friendly, whether you use a library or not.

We use JQuery and have lots of success.

[sfllaw.livejournal.com]

Oh, also, don’t you have real continuations now that generator.send() works?

http://docs.python.org/reference/expressions.html#yield-expressions

[mutiny.livejournal.com]

What's wrong with using Django? It does the javascript/ajaxy/fuckery just as well as Rails, and it does everything else better as well.

[neoliminal.livejournal.com]

Some days I wish I wasn't a Drupal guru.

Sigh. I miss Python.

[digitalsidhe.livejournal.com]

I was going to say "Imagine I just quoted your entire third paragraph here", but this comment is going to be so far down the page that making readers scroll back up, count, and then scroll back down would just be mean, so I will quote the whole damn thing:

Behaviour-driven development is also a great tool for the "design the UI first" school of programming, and any project that doesn't follow that school of programming is doing it wrong. (Think of it this way: if you're writing a library, design the API first -- that is to say, write the man page first. If you're writing a web application, mock up the user interface, figure out what the damn thing's going to look like and do all your changing-your-mind about how the UI is going to behave before you start laying down AJAX requests.)

This is very similar to some stuff I wrote a long time ago — particularly the last two paragraphs of the "Interface and Program Better Adapted to Users" subsection.

Needless to say, I completely agree with you. :)

Agile's whole attitude toward documentation (namely, that it's something optional) is one of the things that's always annoyed me about it. I think BDD is a little lightweight, as docs go, but it's damned well better than nothing.

As someone who's been flipping back and forth between PHP, Ruby/Rails, and JavaScript for the past few months: If your style's been going more and more functional, I agree that you should avoid PHP. It has a few sops toward functional programming, but they're pretty weak sauce. In fact, they're downright laughable. Perl's FP options are much better.

Ruby, on the other hand, rather likes FP. In fact, the way I started learning FP was in JavaScript, using Prototype and Scriptaculous... which in turn got all their FP-ness from Ruby and Rails. Ruby likes FP a lot. (Okay, not as much as it likes OO-ness... and one thing it inherited from Perl is that it doesn't enforce either of those things on you. If you want to write procedural Ruby, you actually can... you'll just be wasting most of the language. It'd be like driving a car and never getting past second gear.)

As for Rails and Apache: Phusion Passenger makes it dead easy. If Apache integration was your major stumbling block to Rails adoption, then OMG you have got to check that thing out. Passenger is mod_rails in the sense that it's as easy and tight as mod_perl or mod_php. (I think some other project has the actual "mod_rails" name, but Passenger leaves it in the dust.)

If you like Python, I suspect you will either like Ruby a lot, because there are so many similarities, or hate it, because it's so close and yet so different in so many details. But they occupy very mich the same ecological niche (and Perl used to occupy pretty much the same one, before it faded into the background).

[ab3nd.livejournal.com]

"if you're writing a library, design the API first"

Yes, this. For some reason, it didn't occur to me that there is another way to do this until you pointed out that it's a good plan.

[graydon.livejournal.com]

I'm not sure. The TDD stuff always seemed pretty cultish to me. Maybe I just work on weird programs. I work on two kinds of system.

System-type #1 is one where we're exploring a technical idea, and we don't know what's going to work or how or anything. So it's pure implementation. There's no "interface". It's a technical experiment. We write tests, and those are all hypotheses. Not "requirements".

System-type #2 is a language or machine tool of which there's a well understood set of requirements. They're expressed in terms of a very detailed spec and a ginormous testsuite (tens of thousands of cases), every one of which is completely non-negotiable. These systems typically acquire secondary testsuites as they mature -- the regression suite, the performance suite, etc. -- but again, there tends to be no room for misunderstanding: regression tests are bugs, performance tests are scalar measurements.

In both type of system, the implementation is the meat of the problem; the "surface area" (while typically infinite) is not something we spend any time with customers or "system-consumers" arguing over. So I think the brow-beating about using one or another "TDD methodology" variant ... is directed at a different kind of software?

[barbarienne.livejournal.com]

Speaking form the position of I-understand-about-one-word-in-three ignorance, I always assumed that programmers started with the UI and then worked out from there.

I mean, that seems so obviously sensible. Why would anyone do it the other way? Do they not know any people?

And then it occurred to me that this explains Windows perfectly. Light bulb!

Python port

[skippy-fluff.livejournal.com]

Have you/any of the commenters seen the Python port of cucumber? (http://github.com/cpennington/pycucumber/tree/master) I am not sure how far along it is, but after checking out the links in the original comment, I think it might be interesting to track/contribute to.