[Rspec-devel] rspec features - core vs extensions
dchelimsky at gmail.com
Fri Jul 14 09:35:58 EDT 2006
My initial reaction to the recent addition of should_increment was
pretty negative because I felt as though it violated what I view as a
core ethos of rspec: encourage good design by making it easy to do
things that encourage good design and less convenient to do things
that encourage bad design.
This is a tough nut to crack because "good design" is a VERY
subjective thing, and there tends to be a lot of passion around
discussions of such because of the subjectivity.
The rspec committer group comes from a world in which TDD has been
butchered and we want to foster better TDD through the introduction,
discussion and exploration of BDD. There's a bit of dogma that comes
along with that - it's sort of a rebellion - and while I think it is
important to keep dogma at bay, it's also important to refer back to
it so we remember why we're even bothering with all of this.
Then we have the issue of adoption. We want to encourage people to use
this tool, and some of those people are going to want to use it the
way they are used to using test/unit. So how do we satisfy the needs
of those people without distorting the vision/intent of BDD and rspec?
Personally, I think the rails model is the one to follow here. The
rails committers turned off a lot of people by not trying to turn
rails into something it is not. The rails plugin system has resolved
this problem by offering an entry point for anyone to use rails
virtually any way they want without bloating core, distorting their
vision, or committing to supporting things that go against their
I'd like to take the same approach w/ rspec. I think we should not be
adding expectations like "should_increment", but we absolutely SHOULD
provide a mechanism for anyone to write custom extensions and a
mechanism to publish those extensions for community use.
If you got this far, thanks for your time reading this.
More information about the Rspec-devel