I read an article on the state of testing in Cocoa. The author, Alex Vollmer, paints a pretty dismal picture of BDD in Cocoa community and I’d have to agree with him. In my decision to use Ruby over Python for my web apps, I mentioned that BDD (Cucumber and RSpec) and the Ruby testing culture was a major reason I went with Ruby. I would really love to see that aspect come over to the Cocoa community. Alex believes that snobbery and elitism are dominant attitudes that prevent the community from adopting testing practices from other environments. I haven’t dealt with the Cocoa community at large, so I can’t comment on the snobbery and elitism, but I do know that XCode and the various Cocoa frameworks didn’t grow up in a BDD world and the fact that the community didn’t grow up with BDD, like Ruby and Rails, makes it a lot harder to inject.

I know there’s been some work to use Cucumber with the Simulator, but that requires you to drop out of Xcode. I’ve gone down this path before, I don’t want to switch between editors and shells for my development environment. I want to see Cucumber and RSpec equivalents that can be run from within XCode. For me, it was running those two in combination while going through The RSpec Book that was my aha moment for BDD and I think it would be the same for the entire Cocoa community.

I was BDDing some code for an idea I had for a Church Year website. I was using RSpec to drive the code that would return the church season based on a date. Some seasons are based on a fixed date, like Christmas, and others are relative to another date, Advent starts 3 weeks before the Sunday before Christmas. I didn’t document all the steps I took to write the code (I’m thinking of doing this as a kata), but what I wanted to point out was that at one point, I was “in the Green” and saw a bunch of duplicate code, ill-named method, and obscure variable names. I started making changes left and right while running the tests after each change and remaining “in the Green.” The experience was amazing to say the least. I hadn’t felt so proud of my code or excited about programming in a long time. I’ve always intellectually believed in the benefits of BDD, but that was the first time I’ve felt it emotionally. I can see why some people refuse to work any other way.

I’ve done it again and decided to change the technology I’m going to use to build LaG. Some my attribute this to technological ADD which I freely admit to, but this time I believe my reasons are substantive.

Uncertain Future of App Engine Patch

I was pretty excited about being able to use Django on Google App Engine with App Engine Patch. However, in recent weeks I noticed that most of the questions to the mailing list were only responded to by the original poster. I personally experienced this when I had a question about a problem loading fixtures and didn’t get a single reply. Then a recent thread on the future of App Engine Patch stated that the maintainers were looking into using a new Django-based framework. Well, I’m just not willing to invest my time in a dead framework. Strike 1.

Wary of Google App Engine

I’ve always been concerned about being locked into App Engine, but the lure of hosting that was free to start and could be scaled with usage needs was very attractive. My desire for a solution that is cheap to start and can scale with need is still very high, but I think there are enough ~$20 per month VPS solutions out there that I’m willing to forgo the $0 starting point for more freedom, control and flexibility. Check Swing.

Desire to Focus on Testing and BDD

Since I’m going to be the only QA for LaG (aside from the users , I really want to have as much automated testing in place as I can. Django and Python have plenty of facilities to do unit testing and BDD, but the community as a whole doesn’t focus much on it and there don’t seem to be a whole lot of best practices around it. While googling Python BDD, most of the references were to say, “We can do that with Doctest and py.test,” but not a whole lot of examples.

Back to the Bad Boy of Software Development

Since I was reevaluating my technology choices, I decided to check in on Rails which I hadn’t looked at in 2+ years. Part of the reason I moved away from the Ruby/Rails scene was that it seemed that things were always changing and not in just subtle ways. I felt like I couldn’t keep up with all that was going on and wanted more stable, measured approach to my choice of frameworks. Well, things haven’t changed much. There’s Rails + Merb = Rails 3, RSpec, Remarkable, Cucumber, etc. all still evolving at fast, if no longer breakneck, speed. But there was still the focus on testing and high quality code. There are also a lot of solutions to help with deployment that didn’t exist 2+ years ago. So I’m reacquainting myself with Rails and RSpec and getting an introduction to Cucumber by going through The RSpec Book beta. I’m feeling pretty confident that this will be the technology I stick with, but I’ve told myself that before.