Well, the grand day has come when I’m finally going to implement a real template for my blog here. However, for the moment, it’s a little incomplete, as you can see. I’ll polish it up soon, so bear with me. At least it’s not totally unstyled, right?
September 2007
Rails, RSpec, Autotest, Redgreen, and Snarl: Reasons I don’t like Windows
In preparation for an article I’m writing on RSpec, I decided to revisit setting up my preferred RSpec development environment in Windows. I was ever so quickly reminded of why I made the switch to Linux in the first place.
The Background
Let me get everyone caught up to speed. RSpec is of course a Behavior Driven Development framework for Ruby and Ruby on Rails. The Behavior Driven Development process itself involves writing a specification (test), running that specification (which will initially fail), writing the functionality to satisfy that specification, and finally running the specification again which should then pass. This process continues until you’ve implemented all the functionality in the application you are developing.
Now, if you run all the specifications manually, this can get really bothersome very quickly. This is particularly aggravated in a Windows environment, since all the common Rails tasks (rakes, generations, migrations, etc.) seem to take twice as long as they do in a Linux or OSX environment. Even under Linux or OSX, though, the frequency of running specs tends to slow down the production cycle incredibly when run manually.
Thankfully, there’s ZenTest and more specifically the autotest functionality of ZenTest. Autotest watches for file changes and then automatically runs any specs or tests that have changed. Combine this with the color-coding provided by Redgreen and a notification system (Growl, KDENotify, Libnotify) and you have a very effective Behavior Driven Development environment.
The Specs
There is strong indication that all of the issues I have noticed are version dependent (i.e. broken in newer versions), so it makes sense, then, to provide the specs of the various gems and plugins I’m using for these tests:
- Windows XP SP2
- Ruby 1.8.6
- Rails 1.2.3
- ZenTest 3.6.1
- RSpec 1.0.8
- Spec:Rails 1.0.8
- Redgreen 1.2.2
- Ruby-Snarl 0.0.8
- Snarl 1.6
The Issues
But then there’s Windows. On the surface, it looks as though the same should be possible here. We can develop Rails apps in Windows. RSpec, Autotest, and Redgreen are operating system agnostic. There’s even a fairly mature notification system for Windows in Snarl. So what’s the problem? Well, when you put all of these together, it explodes.
I did a good bit of trial and error debugging tonight trying to pin down the exact problem, and while I was ultimately unsuccessful, I was able to notice certain trends which, to a more apt Rubyist, may spark an idea for a solution. So, for posterity, I want to post my findings in the hope that someone can figure out what is wrong.
Autotest and Redgreen
A great deal of work has been done to integrate RSpec and Autotest, and in Linux and OSX, the two play very nicely together with little to no configuration. In Windows, however, Autotest initially hangs when trying to read the specs. The only way I could find to get Autotest to actually run the specs through, was to remove everything from the spec.opts file in the spec directory of the app in question.
Unfortunately one of the lines in the spec.opts file is the “–colour” option which sets up the color-coding of passes and failures. I did quite a bit of research online, and found many articles which tell you that you must install the redgreen gem in order to get color-coding on your tests. However, this seems to be outdated information since both Autotest and RSpec seem to come with this functionality out of the box, now (assuming you have installed the win32console gem to make it work in Windows). Indeed, even without the redgreen gem installed, if I simply ‘rake spec’ the color-coding is there.
So, after realizing that I could not rely on this out of the box functionality in Windows, I tried the alternate route of installing the redgreen gem and then requiring it in a ‘.autotest’ file in my RAILSROOT (require ‘redgreen/autotest’ along with require ‘Win32/Console/ANSI’). However, this resulted in autotest erroring-out on load complaining of an ‘Invalid Option: -O’.
I then realized that Autotest has a redgreen plugin of its own, which can be reference as flip-flop of the previous require for the redgreen gem (i.e. require ‘autotest/redgreen’). So I uninstalled the redgreen gem, changed the require in .autotest, and ran autotest again. This time it loads fine, but without color-coding still. Finally, just to be thorough, I reinstalled the redgreen gem in the hopes that it still somehow provided some functionality for the autotest plugin of the same name. However, this two proved fruitless. Autotest still ran successfully, but still without color-coding.
Autotest and Snarl
At this point, I gave up on having nice color-coded test results. Snarl, I thought, can be setup to provide all the visual indication necessary, so I began to work on the Snarl side of things. I already had Snarl installed, so I went ahead and installed the ruby-snarl gem which sets up the connectivity. Then, I opened my .autotest file once more and added the require for snarl (require ‘autotest/snarl’). Time to test it out, so I went to my command line, ran autotest once more, only to see Snarl pop up with a notification window saying all tests had passed, while autotest simultaneously informed me that I had two failures. This is pretty much where I stopped because I have no idea where to even begin to troubleshoot Snarl.
The Summary
In the end, the only thing I could get to work was plain-jane autotest, which is better than nothing but not by much. Through all the digging I have done online, the only thing I can determine definitively is that at one point it was possible to integrate all of this in Windows. However, this was before both Autotest and RSpec added in their own implementations of Redgreen. The Snarl issue is even stranger, and I’m not sure if it is a related issue or something entirely separate.
The ironic part is that it appears that it has been so for quite some time, and no one is either using Windows to notice it, or cares enough to fix it if they have noticed it. Which gives even greater weight in my mind to simply abandon Windows for Rails development, preferring Linux or OSX. Obviously, OSX would be the optimum choice, but for those of us still on PCs, Linux is as close as you can get.
An Introduction to Behavior Driven Development
The logical starting point would be to define what Behavior Driven Development is, but it’s difficult to jump right out and explain exactly what it is, until you first explain what it is not. To do that, I’ll have to digress a bit, and discuss Test Driven Development.
Some of you who read this will likely already have a good grasp of what Test Driven Development is, so you can skip on to the next section. However, for those who, like me, put the cart before the horse on a regular basis, read on.
Test Driven Development
Test Driven Development is a programming methodology, which has gained quite a bit of ground in the software development world. The old practice was to jump into your code, develop all the features of your application, and assume that you are a coding god and did everything correctly. Those who were wise enough to recognize their mortality, would test their code at the end of the development process, but there were still problems inherent in this approach. First, since testing was at best an afterthought, many times it was never completed or not every aspect of the system was tested. Second, testing was expensive, both in terms of dollars and time. Good code went through planning and implementation phases already, so testing simply added a third layer to the process requiring further resources. Test Driven Development counters this old rationale by saying let the test define the system, rather than the system defining the tests. Essentially, then, planning becomes merged with testing, saving an extra phase in development.
So, the heavenly choir sings out in loud chorus and all is right with the world, correct? Not exactly. While the ideal of Test Driven Development was brilliant, its implementation left much to be desired. Everything still centered around the idea of a test, and because of that, the tests were still at least partly defined by the system. Put another way, although tests were being used to define the system, they were still tied to the system itself. If for some reason, the system had to change, any associated tests would start to fail. At that point, the developer is forced to rewrite the tests and we’re right back where we started, testing after implementation.
Behavior Driven Development
Enter Behavior Driven Development. Behavior Driven Development is not a departure from Test Driven Development, but rather, a refactoring thereof. Where Test Driven Development is about proving a piece of code works, Behavior Driven Development is about describing what a piece of code should do. It’s a subtle difference, but an important one. It’s a move from verification to specification, from testing state to testing interactions.
Process
So how does Behavior Driven Development work? It begins with a specification. A specification is an executable description of some functionality in a system. The term “executable” is used here because specifications are in fact written via executable code. However, I like to think of it based on a close synonym: actionable. A specification is an actionable description of some functionality in a system.
I should be able to take my specification and write the code for that functionality in the system with no further information required. More to the point, anyone should be able to take my specifications and implement the same system I have created. We are in fact “specifying” what our application does, how it acts, and how it behaves.
Once our specification is in place, it can be run, resulting in a failure. Failure has a negative connotation in most areas, but in Behavior Driven Development, a failure is a good thing. Nothing has been implemented yet, so the specification fails. This is a call to action. Now it’s time to implement the behavior. Having done so, the specification is run again, and this time it passes. Hooray!
The approach sounds simplistic, but it is in fact extremely powerful. Because we have developed in this way, we can now make some confident assertions. First, we have accomplished something. Our application now has functionality where before it had none. Second, we know that the code is correct and bug free. Finally, and most importantly, we know that our application does exactly what it should do.
With that surety firmly in place, we write another specification, watch it fail, implement the behavior, watch it pass, and so on. Not only does this process grant confidence every step of the way, it also serves to break down our application into manageable bits. The focus shifts from developing an entire application to developing pieces of functionality that come together to make an application.
In Conclusion
That does it for my introduction to Behavior Driven Development. I have intentionally tried to stay away from both a technical and a philosophical approach to discussing this concept for two reasons. First, others have already done that better than I can, and second, I wanted to convey the true value of using the methodology. In my next post, I’ll begin looking at rSpec, a Ruby framework for Behavior Driven Development.
Problems and Distractions
So, I doubt I have many readers at this point, but in case anyone has tried to access my blog, they undoubtedly came across a happy 403 Forbidden error. I knew this was occurring, but simply didn’t have the time to try to figure out why. Obviously, I finally did get the time, tonight, and was able to bring my little blog here back online.
The problem? Somehow, the permissions on my document root went wonky and read-access was denied to the outside world. I remoted in, changed the permissions, and all is once more right with the world. That covers the problems, so what were the distractions?
My chief distraction, of late, has been Ruby on Rails, or more specifically, rSpec/BDD in Ruby on Rails. I started the process of learning Ruby and Rails last month and came across a mention of the rSpec plugin. Curiosity got the better of me, and I started down the rabbit hole of BDD, or Behavior Driven Development, which rSpec provides a framework of for Ruby in general and Ruby on Rails.
The learning process has been slow going, though, because I’ve found much of the information online pertaining to rSpec to be outdated. For some reason, very little documentation exists for the framework in the first place. Combine that with the rapid development cycle of rSpec and the sometimes drastic refinement of its interface and you end up with a very confusing landscape. So, in the interest of documenting my learning process and of providing some more current and extensive documentation on rSpec, I’ll likely begin posting quite a bit more on these matters.
