Three-day log - April 17-19, 2009

This entry will count for three days — I didn’t complete a log on Friday for various reasons, but I continued to work and learn this weekend, so you’re getting a three-fer!

Unit-testing Javascript ain’t so bad! Thanks to a little courage and a nice pair-programming session with Scotty Moon, I was able to make headway on doing TDD in Javascript – it seems, like any kind of TDD, you just have to jump in and try it. I initially chose Dr. Nic’s JsUnitTest because of its simplicity, but I feel like I may switch over to JSSpec or Screw.Unit at some point. I miss the RSpec-like syntax, but I don’t use jQuery so I was a bit uncertain about those frameworks.

One should be enough. The control I’m trying to unit-test is really a combination of 3 smaller behavior classes, with the fourth behavior being the glue between them. Naturally, to keep things separated, I wanted to create test-cases for each individual control. However, things get “interesting” when you have more than one Test.Unit.Runner in your test-page, especially with test methods that use wait(). When I figured out the separate runners were causing the problem, I collapsed them into one, and voilà, my Ajax mocks started working properly too! I’d love to have some way to run multiple suites in one file, but that’s a project for some other day.

Yes and no. At one point, I struggled with how to simulate a click on an element in a test. It seems there is no reliable, cross-browser way to do this, but I found a couple of resources that gave me some clues. For testing, it’s a necessity unless you want to have to click something every time you run your tests. Luckily, I found Dr. Nic’s add-on to JsUnitTest that adds Event.simulate (and the Ajax mocks I spoke of above). In most cases, it does the job admirably, and as a bonus it adds some nice methods to easily trigger the events if you’re using Prototype. For my case, I just call _click() on the extended element.

You’ve got issues. Github unveiled their new issue-tracker this weekend. With the move of the Radiant wiki over there, it might make sense to make our ticket system on there too. It seems very simplistic but straightforward, and I like the idea of voting for issues that you want solved. We’ll definitely be moving toward this for extensions.

Another one converted. I’m helping an acquaintance who is working on a Rails app by doing weekly code-reviews for him. Because he hasn’t fully drunk the testing Kool-Aid yet, it’s been difficult to convince him to start building a test-suite (“What’s the point? I don’t get it.”). However, this weekend I think I finally got him to take a sip! I wrote an extensive email about some refactorings I wanted to suggest and ended it by pointing out how the design patterns I employed were borne out of experiences doing TDD: small methods with clear purpose, limiting functional side-effects (or keeping them explicit), appropriate assignment of responsibility, making domain objects more informative about themselves. I also explained the purpose of Cucumber: identifying the business value first, then defining the feature. In the end, he tried Cucumber and seemed to like it! WIN. Take heed young Padawans, do not build features that have no business value. They will cost you much more in the long run.