Specs for RSpec Matchers and Helpers

Testing RSpec
1

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

2

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

3

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