Specs for RSpec Matchers and Helpers

Hi,

I’ve been extracting a lot of code out of my specs into their own
matchers,
helpers, and macros.

I notice that the plugins that have their own specs, such as
rspec-rails,
and even RSpec itself, have specs for the matchers and helpers. Is this
generally a good thing to do, or is it unnecessary?

Brandon

On Wed, Apr 15, 2009 at 4:52 PM, Brandon O.
[email protected]wrote:

Hi,

I’ve been extracting a lot of code out of my specs into their own matchers,
helpers, and macros.

I notice that the plugins that have their own specs, such as rspec-rails,
and even RSpec itself, have specs for the matchers and helpers. Is this
generally a good thing to do, or is it unnecessary?

Overkill, unless they are really complex, which they shouldn’t be. Usage
of
the matchers in specs should be good enough. If it isn’t your matchers
are
too complex. Strive for cyclomatic complexity of 1 in all test code.
(no
branches).

Aslak

On Wed, Apr 15, 2009 at 7:52 AM, Brandon O.
[email protected] wrote:

I’ve been extracting a lot of code out of my specs into their own matchers,
helpers, and macros.

I notice that the plugins that have their own specs, such as rspec-rails,
and even RSpec itself, have specs for the matchers and helpers. Is this
generally a good thing to do, or is it unnecessary?

The main difference is that they ship their matchers and you don’t. If
their matchers have bugs, then their product has bugs. Not necessarily
so with your matchers.

In general, test code is simpler and more obvious than the code it
tests. So we don’t have to test our tests. But it certainly doesn’t
hurt, and if doing so increases the comfort level to a desired level,
then by all means do it.

Finally, much code can benefit from TDD, including matchers.

///ark

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs