State of Remarkable 4

[Ho-Sheng Hsiao]

Hi everyone,

I've gotten a request from someone off of Github asking about the
status of Remarkable 4. Considering that Rails 3 is out and Rspec 2.1
is out, it is reasonable to expect an official, non-beta version of
Remarkable capable of working with Rails 3 and Rspec 2.

Here is my thinking on this:

(1) I specifically don't use the i18n. I know some people here have.
Since I don't personally use it, I'm not really "scratching my itch"
so any work I do will not be as passionate or enthused as someone who
actually needs this feature.

(2) Taking i18n out of the picture, Rspec 2 provides many of the
syntactic sugar from Remarkable 3 out of the box. Shoulda provides
many of the ActiveRecord macros we expect, again out of the box.

(3) Remarkable-core was written with its own set of DSL and classes.
There is actually a very competent expectation DSL built into Rspec-
core 2.0 right now -- again, no i18n out of the box. I actually find
using that far less confusing than the Remarkable-core DSL. My guess
is that it was modeled on Shoulda, and one reason I switch to using
Rspec is so I can see describe do end block not asserts_this, or
asserts_that.

(4) Rspec 1.3 introduced the least well-known feature that all Rspec
users *should* be using. Something called let(). Along with metadata
in Rspec 2.0, these two combined provides a very powerful *built-in*
mechanism for creating your own DSL.

I'm actually sitting on a pure-Rspec DSL for generating Rspec tests.
Here is a sample test:

-------------

require 'spec_helper'

describe MyWebService::Application do
include SpecHelpers::Rack # This is where it adds the DSL
include SpecHelpers::Application # These are application-specific
stuff

context 'when successfully authenticating' do
let(:http_headers) { {
'X-Auth-Identity' => access_credential.identity,
'X-Auth-Key' => access_credential.key } }

request :get, '/auth' do
expects_status(204)

it 'should respond with a valid X-Auth-Token header' do
response_headers.should be_include('X-Auth-Token')
AccessToken.authenticate!(response_headers['X-Auth-
Token']).should eql(account)
end

end
end

context 'when not successfully authenticating' do
let(:http_headers) { {
'X-Auth-Identity' => 'no identity',
'X-Auth-Key' => 'no key' } }

request :get, '/auth' do
expects_status(401)
end
end

end

------------------------

This spec tests behavior similar to the Rackspace Cloud API, using X-
Auth HTTP headers to do the authentication. The actual authentication
piece is a Rack middleware, but as you can see, I'm directly querying
the Rails application itself. There are a number of macros there that
will not just test the status, but also the return body and return
headers.

This piece of code is in a single file of 117 lines. It has no
dependency with remarkable-core. The code is written in 100% Rspec 2.
There is 0% i18n. There is actually 0% dependency with rspec-rails.
I'm not testing assigns or controllers or rendering. I inject a Rack
1.0-compliant headers and the macros parses and test Rack 1.0-
compliant responses. Theoretically, you can use this test Sinatra
endpoints. Since Rails 3.1 will make more use of Engines and I expect
Engines will be mountable Rack applications, this piece of code will
be very useful.

There are a lot of reasons I've been sitting on this. Part of it is
that I've been busy getting my employer's new site launched. That's
over with. The other was getting permission to open source this. I've
gotten that. The last thing comes with the Remarkable community.

I'd like to get this out as remarkable-rack. In fact, I'd like to
publish a few more rspec DSLs like this. The big caveat is that code-
wise, this has nothing to do with Remarkable. I hate to say it, but I
found it easier to write this with pure Rspec than to use Remarkable-
core -- especially since I don't need i18n.

So my question to you guys: what do you think? Where should we take
Remarkable? Its biggest advantage over every other rspec-helping gem
out there is i18n, which is something I'm very reluctant to maintain.
I don't see a point in calling this Shoulda for Rspec, especially now
that Shoulda works with Rspec (since 1.3). And its biggest selling for
me personally, the macro system, has been superceded by the an easier
set of semantics baked directly into Rspec 2.0.

I will be going to RubyConf in New Orleans. If any of you want to
speak to me about this at the conference, let me know. You can reach
me at +1 678-561-5652.