photo by Kriston Lewis

I am a big RSpec fan. But occasionally, I work on projects that use test/spec. When I want output the spec documentation with RSpec, I just use rake spec:doc. With test/spec, I couldn’t find such a thing. So I made one and stuck it in lib/tasks/test_spec.rake

Rake::TestTask.new(:specdox) do |t|
  t.options = '--runner=specdox'
  t.libs << 'test'
  t.pattern = 'test/**/*_test.rb'
  t.verbose = true
end
Rake::Task[:specdox].comment = "Generate specdox."

Now I can use rake specdox to see all the wonderful spec documentation!

photo by vitalyzator

I presented on RSpec 1.1 tonight at the Dallas.rb. I don’t claim to be an expert, I just love my specs (and now stories).

Feel free to take a look at the slides.

photo by laffy4k

So I came across Dan Manges Fixture Factory as a way to relieve myself of the pain of fixtures for testing. I don’t mind fixtures that much, but when I have to start setting up so many different combinations, it gets a little challenging. In reading through the comments I found that Scott Taylor had implemented it as a plugin. Now I get all that goodness for my specs.

The other day I wanted to play with some things using script/console, but was feeling too lazy to set up all of the data I was going to need to do what I wanted. Sure enough after looking at the documentation for fixture_replacement, I can use it there too:

  % script/console
  >> include FixtureReplacement
  >> cause = create_cause
  >> user = create_user
  >> cause.users << user 

It is really useful for easily setting up your test data in the spec (or test) that you are writing. Instead of having to go off to the fixture files and add new fixtures (and try to remember to set up all of the dependent fixtures that are needed), you can use new_xxx or create_xxx to get an object to test in a valid state with all its dependent data.

Take a look at the FixtureReplacement plugin now.

photo by alangbrf

I will give a presentation on RSpec and Behaviour Driven Development at the Dallas.rb tonight (August 8). Stop by and find out more.

Because my friend Matt was so impressed with a Firefox extension I showed him, I thought I would share some of my other favorites.

photo by longhorndave

What Extensions I Am Using Right Now

• Web Developer Toolbar - Just about everything you could want to do HTML and CSS, plus I can edit AND save the CSS changes I was playing around with.
• Firebug - So much goodness. Especially debugging JavaScript and looking over AJAX requests and responses.
• View Source Chart - Makes looking at HTML source bearable.
• ColorZilla - a color picker for pulling colors off of web pages.
• HTMLValidator - because it is too easy to miss a closing tag somewhere that messes everything up.
• DummyLipsum - when you need some filler content.
• SeleniumIDE - great little utility for helping to write Selenium tests for functional testing.

photo by meshmar2

Not to mention

• Adblock - no more ads.
• Adblock Filterset.G - no more ads just got easier.
• GTDInbox - for when I think that I am Getting Things Done
• Foxmarks - because I have too many computers and too many bookmarks.

Got a favorite? I’d like to hear about it.

photo by zruvalcaba

After my last post, I thought I would share what I use for developing on Ubuntu.

Editor

I have always been a hands-on kinda guy, so I don’t use any of the fancy IDEs. Right now, I am using SciTE for two reasons. It feels lightweight and it is available for Linux and Windows. Since my laptop does not have a lot of memory, a lightweight editor is a must. I tried Eclipse, but it chewed up all my memory and slowed things to a crawl. So SciTE with some additional plugins (and information on getting them going) powers the development at McKinney Station.

Ruby and Rails

I am using the latest Ruby and Rails for all new development. For testing I am using RSpec, which seems a lot more intuitive to me. Other gems I have installed include:

• FasterCSV - parsing CSV files
• starfish - simple Ruby Map/Reduce
• mongrel - lightweight Ruby web server
• hpricot - Ruby HTML parser

Database

I love starting all of my development projects with SQLite. It is so easy to get up and running. As the project matures, I am able to quickly switch development over to a MySQL database with a change in the application’s database configuration and a quick rake db:migrate.

Version Control

All source code versioning is done with Subversion. With this quick little script, I can get a Rails project committed and started in minutes.

Conclusion

I am always looking for ways to speed up my development process, but so far this is working for me. And it is very enjoyable.

photo by bjearwicke

I have come across a few situations recently where testing is a second class citizen in the development process. The latest was a job posting where the part of the development environment was described as “testing when possible.” A lot of the larger projects I have worked on have 1 or 2 weeks of testing tacked on to the end of the development cycle. More times than not, this “testing” time becomes padding for development schedules that overrun. Besides “you tested as you developed, right?” and “we can’t move the delivery date.”

I am becoming more and more an advocate of writing automated tests. This has become even more important when I am the sole developer on a project. Now you might say to yourself, “If there is no one else to mess up the code, shouldn’t everything work?” It does work. But as I come across areas of code that need to be refactored, because I am DRYing up my code, I want to be sure that my changes do not break existing functionality. Now I could make the changes and then manually try to test all of the possible scenarios, but I usually miss one or two, especially in more complex applications. This is where the automated tests come in very handy.

photo by mcconnell6

Maybe I am thick, but writing tests using JUnit or Test::Unit never seemed natural. It always seemed to go at the end of my development cycle. Maybe it was the vocabulary implying that something had to exist to be tested. Maybe it was the unnatural language of assertions: assertTrue, assertThis, assertThat. Who talks like that?

Then I came across something that encouraged me to write specifications for an application that could then be used after the development was complete to verify that the specifications were met. All of the sudden I was discussing how the application should behave, which does not imply that the application even exist yet. This makes sense to me. I saying things like “this should equal that” or “something should have 5 of these”. It is subtle, but powerful.

So I am now using RSpec, the Ruby implementation of Behaviour Driven Development, for all of my projects. My latest Rails project has only 6 models and 2 controllers, but has over 200 specs. I have a better understanding of how the application is supposed to behave. Combine that with a way to continously re-run the specifications when the code is changed and I am now a lot more confident that my changes aren’t breaking existing functionality.

Plus, it’s cooler, right?