Shoes, posture, code?

Comment

Comment by Kurt Sussman on September 3, 2008 at 1:38pm

Laurence, I feel your pain. And I agree completely that BDD won't catch all my bugs. It also won't push my code toward DRYness, nor alleviate the pain of unexpected bugs in other people's code. Real testing is still required before 'shipping' a web app.

An old officemate of mine, Mark Fox, said that programmers do two things: debugging and enbugging. I think that writing tests minimizes the time spend debugging. There will still be bugs, and some will still be painful. But most of the stupid bugs will be caught by my tests, leaving only the challenging bugs for me to deal with manually.

Comment by Laurence A. Lee on September 2, 2008 at 11:13am

Kurt, thankfully that article wasn't one of mine (yeah, I noticed lots of errors in it too), but it did a good job of articulating the problem/solution anyway. I'm not discouraging writing good unit tests, I just think it's a lot of effort for what's essentially an incomplete (false?) sense of security.

IMHO, Rails Coders rely too much on Unit Testing to consider their code "good enough for production". A good example of this that recently nailed me is a little bug in polymorphic_routes.rb.

Despite polymorphic_url's method signature accepting an options hash, it didn't really do anything with the options hash (at least through Rails 2.1.0).

I lost half a day trying to figure out why my extra query parameters weren't showing up in links, going over documentation and questioning my own code because "it's calling Rail Core, so I must be doing something wrong".

I'm a little irritated it took this long (the entire Rails 2.x line including Rails 2.1.0) before this issue was discovered and fixed; and a lot more irritated at myself for blindly trusting the Rails Core team for that long. In fact, the more I work with Rails and monkeypatch the glitches, the more I realize the truth in Zed Shaw's Rails-Ghetto Rant. *Sigh*.

Comment by Kurt Sussman on August 31, 2008 at 5:38pm

Haken, I will climb the stairs on the Eiffel tower next time I'm there. We've been invited to a wedding in Paris in December, don't know if I can afford it though. I would rather climb it semi-barefoot, but not in December!

The almost-automagic API is one of the reasons I'm using Rails. I know that I can't imagine every possible use for the data my system collects; what's the harm in letting people create stuff using their own data? It also allows me to create a desktop app using something like Shoes. I really want to play with that. While I have evaluated APIs, written test plans based on API docs, etc, I don't have the experience creating them from scratch to do it perfectly the first time.

Laurence, I like that article, but it could use a few tests. :) I found some typos, mostly in the code.

I'm trying to decide between make_resourceful and resource_controller right now, so it looks like I agree with you at least to that point. Calling a well-tested super fits perfectly with my BDD path, and increasing DRYness is always a worthy goal. I agree that tests can be ugly, but I've found through experience (mine and others') that failing to test is like sewage in rusted pipes; it's gonna stink eventually.

Writing good tests is as hard as writing the code to be tested, sometimes harder. Dealing with the potential problems that result from Ruby's 'duck typing' are tedious. 'validates numericality of' only goes so far.

Comment by Laurence A. Lee on August 31, 2008 at 3:03pm

Actually, I'm kind of sitting on the fence when it comes to automated unit-testing. On one hand, it is good to know that your known test-cases (the ones you anticipate) are functioning properly. On the other hand, you can't anticipate all entry points unless you have good automated tools to weed them out. Thus, even if your unit tests pass, some punk kid could still find a hole to exploit.

I find unit testing to be especially bothersome for loosely-typed languages like JavaScript and Ruby, where foo could be assigned a number or a string, and you have to do explicit casting to ensure the expression foo + bar evaluates to 3 and not "12". There are just too many "stupid things" to test against and add Guards for, and it just makes for uglier code in the end. *Grr*

I think the best bang-for-buck to slim down code complexity is to spend time identifying any repeated Patterns in your models and controllers, and see if you can DRY up your code along those lines. I know, that's so cliche for Rails.. but it does pay off.

Aside from a few oddball Rails Actions, most of my controllers implement RESTful CRUD, so I've refactored that out. Some will argue it's confusing to hunt for the Base Class that implements the RESTful CRUD actions, whereas I view such code as uninteresting background noise. When I'm working on a controller, I'd much rather see the controller-specific enhancements to the create and a update method with a call to super at the end, rather than wade through all the CRUD cruft that's typically generated by a Rails Generator.

While not exactly the approach I've taken, this blog article describes this in much more detail.

Comment by Cameron Souza on August 31, 2008 at 12:18pm

As you implied, I believe the key is good "coding posture" is test driven development. Systems with heavy unit test coverage are easy to evolve and extend because you know right away if you have broken something. With scripting frameworks like RoR this is particularly important.