I have read the so-called rules of test-driven development. As a rule, you are supposed to write tests first, run them and make sure they fail, then write the minimum amount of code to make your test succeed, make sure the tests pass, and repeat. Long have I skipped this first part. Running a test to make sure it fails before you write code that makes it pass, that is. It always seemed redundant.
Today for laughs I took an old module of mine and started it over from scratch and followed the above procedure. A funny thing happened: some of the tests that I expected to fail actually passed without my having to write any code. For example it turns out my class inherited a
:to_s method from its parent and that did exactly what I wanted, without my realizing it. The end result after an hour or two was about 60% less code than the original module for a module that does exactly the same thing (i.e. passes all the original module's tests), and the code I ended up this time with probably works better. It's certainly cleaner. So maybe there's something to these magic rules. We'll see.
My theory of learning to program (or learning in general) is that there's always something new out there that I haven't found yet. A lot of it is crap, but some very small portion of it is really good. So I make sure to take some time every once in a while and read something completely alien to me, to test the waters. And to keep things fresh.
This week, it was RSpec and "Behavior-Driven Development". My buzzword detector went off at first, but it seems interesting. The idea is to change the wording used when writing unit tests, from something like
assert_equal X,Y to something like
X.should == Y. The idea being that the latter terminology somehow helps you write tests that are more in tune with what TDD is supposed to be driving you toward: not testing after-the-fact, but rather building up a real programmatic specification for your code before or as you write it.
There's more to the whole thing than that, obviously, but that's part that stuck with me. It's a matter of language choice (not programming language choice, but class/method/variable name choice within some programming language). Linguistics has always fascinated me, and I do think there may be some credence to the argument that a simple change in terminology can affect how people think about a problem. Word choice is a powerful tool.
Whether this thing has any real value for writing good code is yet to be seen by me. I am always a bit hesitant to drink the kool-aid. RSpec itself is nice though. It really shows off the power and expressiveness of Ruby, in how it works.