Taking queues from Adam Wiggin’s first commit to his Rush project, simply a design document and some specs, and Err the Blog’s post about BDD and generating specs from YAML, I’ve written a small Rake task that will take a single file design document in YAML and separate it out into the components you specify. For example:

spec/design.yml

Website Integration:
    - should be able to log in from the front page and land at your profile
 
OpenID module:
    - should accept an OpenID URL
    - should return an error message if the URL cannot be reached
 
User:
    - should have a valid user name
    - should return an error if creating a duplicate user name is attempted

And then:

rake design

Takes the section headers, and flattens them as the filenames. So this particular design creates three different files, website_integration_spec.rb, openid_module_spec.rb, and user_spec.rb. They’ll look like this:

spec/user_spec.rb

require File.dirname(__FILE__) + '/spec_helper'
 
describe 'User' do
 
  it 'should have a valid user name'
  it 'should return an error if creating a duplicate user name is attempted'
 
end

And just like that, you have your specs, ready to go!

Here it is:

Please note that it will destroy those files if they already exist, replacing them! I really don’t care if you lose your existing specs! Back them up if you want to try this! You have been warned! This is more of a technique for a brand new project, anyway.

Also, please note that I’ve embedded the rake task as a GitHub Gist paste, so feel free to fork it and modify it. I’d be interested in seeing cleaner, more interesting implementations of my 30-second hack. Additionally, please choose view raw if you want to copy it, seeing as how GitHub seems to bork on a newline character in the code snippet.

This is the first release of an evolving library that interacts with the online todo-list thingie Tasko. If you’ve never heard of it, or its brother-in-spirit TaskPaper, you’re in for a treat.

Plain text files, converted to To Do lists with simple formatting rules. Lines that end with a colon are project names. Lines with a hyphen starting them are tasks. Use tags on lines to categorize them. @today, @home, whatever. Tag a line @done to cross it out. Simple!

So now we have Taskomaly, which works on your local machine, interacts with task lists, and can upload them to Tasko using its API. Tasko provides both an API key and a user ID when you register. You need both of these things. Register, then go to your settings page to retrieve them. I suggest placing them in a file in YAML format, like so:

  user: 9999
  key: d9cca721a735dac4efe709e0f3518373

Then, off to irb!

  t = Taskomaly::From '~/.tasks.yml'

Now, get the information you want. Your papers! Make a change, then save them back to the website.

  t.request :papers # ['Paper One', 'Paper Two']
  p = t.papers.first
 
  puts p.name # 'Paper One'
  puts p.body # duh
 
  p.body["@today"] = "@tomorrow"
  p.save # true if groovy, false if failed

This is the first real project I’ve put a huge emphasis on TDD, guided along by the simple principles espoused by Adam Wiggins during his work with the rush shell.

So, yeah. That’s that. Work (and specs) are coming along soon to help you with individual projects inside task papers, searching and using tags, and all kinds of other fun stuff.

EDIT Jesus I forgot to put a link to the project. Here it is. On GitHub. Duh.

Stagger in disbelief if you’d like, but I’ve found an instance where it is more beneficial to not begin testing a piece of software until a measurable way through its development.

You no doubt remember my fabulous, in-development command-line NewsGator client, bulletin. I’ve extracted the NewsGator-specific code to a gem called WonderCroc. The README provides a small glimpse of what’s possible with the library now:

wondercroc

A gem that provides…

In any event, I haven’t written any tests for it yet. A lot of the initial programming was screwing around with Ruby’s RSS parser and running requests through in IRB. At this point, however, I’d like to start throwing specs at it as I refactor it and extend it to become a modular library.

So what?

Well, here’s the thing. I want to know that the library responds correctly to the XML responses sent by NewsGator’s server. I assume the correct way to test this is to mock the responses accurately. The NewsGator REST API documentation provides several partial samples, but they’re not complete or complex enough to give me a full range of parsing opportunities. So why not use actual responses?

So that’s my plan. Extend my WonderCroc::Client class to log the XML responses to a file, and use those in my mocks — something I can’t think of a good way to do if I hadn’t written the code in the first place.

Thoughts?