I have a confession to make. I still only "dabble" at doing tests for
my Rails apps. Well, more than dabble, but not full blown TDD.
A year ago, rspec seemed to be taking over the planet with a tsunami of
"rails space" being devoted to it on blogs and elsewhere. I read about
and watched webcasts a'plenty about rspec, but somehow I just can't seem
to get over the (seemingly) rather large hump of doing enough of it to
get good enough at it that it doesn't completely kill my productivity.
I'm wondering, are there a fair number of you out there who tried rspec,
and gave it a really good go, and then wound up going back to a smaller
amount of testing using Test::Unit?
I keep telling myself I need to take another run at this thing, but I
want to be sure it wasn't another one of those short-lived software
"fads" that everyone touted just because the "cool kids" were saying it
was the way to go.
I'm convinced that testing is good, and that a proper amount of it makes
a world of difference in the stability and maintainability of an
app...I'm just not sure that a full boat rspec implementation isn't too
much of a good thing.
What's the general opinion out there on this now that some time has
passed and more people have had a chance to witness the practicality (or
lack there-of) of doing a full boat rspec TDD approach to Rails
development?
We're using rspec in our company since october 2007 and
by now there's no idea of going back to Test::Unit.
It's just nice and gives tests better readability and allows
to keep tests simple with mocking away things that are
not important or difficult to setup for the current test.
Independent of the testing method:
Tests don't kill you productivity. At leastif you develop
real world software you must test. It's the only reasonable
way to keep your project stable if you have to make changes
later on.
Think you have a small shop, everything works fine and six
months later your customer wants you to implement product
categories, which will change 1/2 of your code.
Without tests you'll get a medium panic, especially if you haven't
worked on the code in that time.
Even without that: Write tests first, then run your code against it.
This gives you a much better overview, what you'll have to
implement and if your design meets the requirements.
(Just checked: The code/test ration of our projects is 1:1 or
better.)
and watched webcasts a'plenty about rspec, but somehow I just can't seem
to get over the (seemingly) rather large hump of doing enough of it to
get good enough at it that it doesn't completely kill my productivity.
Hi Jeff,
I feel your pain. I'm a one-man, contract programmer and get paid by the
hour. I really dig the idea of BDD, and used it for a bit while creating
models (not a very agile approach, though...I knew I needed a boatload
of models and created them up front). But when I got to controllers, I
couldn't wrap my head around mocking and stubbing and was starting to
spend a lot of time reading and experimenting, only to fail again and
get frustrated. While my "boss" is a pretty understanding guy, it's hard
to convince him that not seeing any real code in two weeks is a good use
of his resources. As you put it, my productivity got killed. I tried to
justify it with "it's slower on the front side, but really helps later
down the road", which is true. But when he wants to get this project
done in 6 months, I don't have the luxury of taking the first 5 to write
tests. I understand that a lot of code is really being written along the
way, but right now it's just not clicking well enough in my head to keep
pushing forward with it. I intend to come back to it some day, because I
do think it is the right way to go about it.
To Thorsten's point about testing not killing our productivity: I would
agree with that. What kills our productivity is the learning curve of
testing. It's like someone said in another thread about choosing Rails
for a new project: If the project has to be done soon, the learning
curve of Rails might jeopardize the timeline. The same can be said of
testing. If you already know how to test, by all means test, test, test!
But if you have to climb the learning hill to test, be prepared to have
your "productivity" dramatically reduced.
and watched webcasts a'plenty about rspec, but somehow I just can't seem
to get over the (seemingly) rather large hump of doing enough of it to
get good enough at it that it doesn't completely kill my productivity.
Hi Jeff,
I feel your pain. I'm a one-man, contract programmer and get paid by the
hour.
Peace,
Phillip
Me too. One man shop. Don't feel like I can charge the client for my
learning curve on rspec.
This old dog took to Rails like a Golden Retriever to water...but with
rspec I feel more like a cat.
A side note: there's no reason you can't do full on TDD/TFD but with
Test::Unit and not RSpec (i personally don't particularly like rspec)
Fred
Glad to hear I'm not alone. I kept watching the screencast and thinking
"Oh, I get it". Then I would go and try to do it and I would type "it
should......hmmmmn I know what it should, but I don't know how to write
it....let's try again.....it should.....work right?.....idunno"
It just doesn't seem like I've hit that golden moment where the light
bulb comes on and it starts to click.
Now I've been away from it long enough I'll have to basically start from
scratch if I try again.
To Thorsten's point about testing not killing our productivity: I would
agree with that. What kills our productivity is the learning curve of
testing. It's like someone said in another thread about choosing Rails
for a new project: If the project has to be done soon, the learning
curve of Rails might jeopardize the timeline. The same can be said of
testing. If you already know how to test, by all means test, test, test!
But if you have to climb the learning hill to test, be prepared to have
your "productivity" dramatically reduced.
True of course, especially if you work alone. We're two programmers
doing mainly Rails here (and one doing PHP, HTML, CSS and a smaller
amount of Rails) and we already had enough testing experience with
Test::Unit.
So jumping from Unit to rspec was done in a week, while working on
new projects.
The syntax part is by far the smallest amount of learning i guess.
What
takes time is the "What and how to test?"
And one more point: Testing becomes even more important, if you work
in a team, where several people need to maintain the code and not
everybody
may be aware of every relation one model has to another or other
dependencies in the code.
The syntax part is by far the smallest amount of learning i guess.
What
takes time is the "What and how to test?"
You just hit the proverbial nail on its head.
And one more point: Testing becomes even more important, if you work
in a team, where several people need to maintain the code and not
everybody
may be aware of every relation one model has to another or other
dependencies in the code.
I fully agree with the importance of testing, even for one-man shops. I
was first introduced to the test-first approach about a year ago. As
with many people, it was a complete reversal of everything I'd ever
learned or done. Kind of like agile development: all of my development
life, I had always been a part of something that used the waterfall
method. We had to have complete specifications before a single line of
code could be written, and the specs had to be signed off by half the
people in the company. The QA team didn't see the application until many
months later, and every test plan had to be redone with every simple
change that affected it. After years and years of this, it's difficult
to adjust to new ways of doing things. My biggest adjustment has been
being self-employed. Then, of course, there's Rails. And trying to be
more agile. And here's this testing-first idea. I won't mention source
control
It's been more than enough to make my head spin at times. But, step by
step, I'm getting there. I'm becoming more competent in Rails. I'm
slowly shedding the obesity of waterfall and becoming a bit more agile.
I've at least broached the testing subject. And I'm using source
control, though not as frequently as I should.
I'm at the same point as some of you on this thread. I'm a freelancer
that really wants to get into BDD with rpsec (and be one of the cool
kids but I always find myself stuck in neutral.
It allows for rspec like testing but sits on top of Test::Unit without
affecting your existing tests (I haven't used test/spec but I believe
it works this way too). I'm using shoulda to slowly work in the whole
"should do something" approach.
It allows for rspec like testing but sits on top of Test::Unit without
affecting your existing tests (I haven't used test/spec but I believe
it works this way too). I'm using shoulda to slowly work in the whole
"should do something" approach.
best.
mike
Thanks Mike, this looks interesting. One potential downside is that
clients want to hear buzz words like "rspec". If this is relatively
unknown by comparison, it sorta doesn't count when woo'ing a prospective
client.
The biggest problems I am seeing are:
1) The lack of instructional material.
2) The total absence of instructional material that isn't a year old.
3) The total arrogant disregard by the rspec community of people that
are part of their "in the know" clique.
I joined the rspec user group and politely asked for assistance in
finding learning materials and my request was completely ignored. That
has never happen in the Rails or the Ruby groups. even when I asked
really stupid questions.
I think rspec looks very promising, especially considering the limited
debugging facilities in Rails, but learning it is like pulling teeth
and core team doesn't seem to want to share.
I think rspec looks very promising, especially considering the limited
debugging facilities in Rails, but learning it is like pulling teeth
and core team doesn't seem to want to share.
Agreed on the documentation. To be honest I've always felt that way
about Rails docs too.
Have you seen the rspec screen casts at RailsCasts.com and PeepCode.com?
It's a start.
As an Rspec user, I have to say that Shoulda is not Rspec-like testing really. They resemble each other more in syntax but you’re still stuck in the world of Test::Unit. I miss my view specs, I miss my testing in isolation, I miss my Rspec.
As an Rspec user, I have to say that Shoulda is not Rspec-like testing really. They resemble each other more in syntax but you’re still stuck in the world of Test::Unit. I miss my view specs, I miss my testing in isolation, I miss my Rspec.
Do you maintain specs for your routes also? This is one of the things that overwhelmed me when using rpsec.
Also, do you spec all your views? I could see writing specs for tricky parts.
i do not maintain routing specs. they always seem to me to be little more than assertions that you correctly understand how the routing works. i do spec my views and i’ve learned to spec them very non-brittle-ly. i spec that templates have forms and where those forms submit to [or if they call form_for, for those forms that use form_for @foo to the utmost DRY potential] as well as that they have sufficient form elements to generate specific params [like params[:user][:name], etc]. i wrote a shortcut for this:
def allow_editing(instance, attribute)
instance_name = instance.class.name.underscore.downcase
if instance.send(attribute).is_a?(Time)
have_tag(
"input[name='#{instance_name}[#{attribute}]'],
select[name=?]", /#{instance_name}\[#{attribute}\(.*\)\]/
)
else
have_tag(
"input[type='text'][name='#{instance_name}[#{attribute}]'],
select[name='#{instance_name}[#{attribute}]'],
textarea[name='#{instance_name}[#{attribute}]'],
input[type='checkbox'][name='#{instance_name}[#{attribute}]'],
input[type='checkbox'][name='#{instance_name}[#{attribute.to_s.tableize.singularize}_ids][]']"
)
end
end
so i can use response.should allow_editing(@user, :name), etc. feel free to checkout my pluginized form of these [http://github.com/rsl/skinny_spec/tree/master] [hat tip to rick olsen’s rspec on rails on crack for the basis of a good chunk of the controller specs which i only rewrote for aesthetic preferences of it_should over should.]
3) The total arrogant disregard by the rspec community of people that
are part of their "in the know" clique.
Pardon if this seems arrogant, but that's just absolute pure bullshit.
As the leader of the rspec community I take personal offense in that.
Have you actually read through the archives of the rspec mailing
lists? Check them out at http://groups.google.com/group/rspec and
http://rubyforge.org/pipermail/rspec-users/ for older stuff. The RSpec
community has it's opinionated people (like me) just like any other
community in the ruby space (or programming in general), but all in
all people tend to get their questions answered.
I joined the rspec user group and politely asked for assistance in
finding learning materials and my request was completely ignored.
Please point me to your question and I will personally see to it that
it is responded to. The RSpec list is busy and sometimes things fall
through the cracks. Please don't take this personally. We want you and
didn't mean to ignore you.
That
has never happen in the Rails or the Ruby groups. even when I asked
really stupid questions.
You're lucky I've had several questions go unanswered over the
years on the ruby-talk and rails lists. When I've not gotten answers
right away, I've asked again and eventually gotten what I needed.
I think rspec looks very promising, especially considering the limited
debugging facilities in Rails, but learning it is like pulling teeth
and core team doesn't seem to want to share.
Again, I just don't understand where you get this characterization of
the core team from. Please help me understand so we can make it
better.
I've had several questions go unanswered over the
years on the ruby-talk and rails lists. When I've not gotten answers
right away, I've asked again and eventually gotten what I needed.