Though I’m primarily working on plain old Ruby with a handful of
Camping here and there, I’ve been writing a couple articles about
Rails that might be interesting to the novice-to-intermediate crowd.
My article “Rails Testing : Not Just For The Paranoid” just came out
today, and in it I show unit, functional, and integration testing by
example. It was tough to work in ‘really cool’ examples and keep with
a word limit, but I think it might still be helpful.
My article “Rails Testing : Not Just For The Paranoid” just came out
today, and in it I show unit, functional, and integration testing by
example. It was tough to work in ‘really cool’ examples and keep with
a word limit, but I think it might still be helpful.
Gregory,
Thank you for the article you posted on testing. I went through this
and your examples this morning and feel you could help people more if
you taught them the ‘rational’ that would help one find the right
coding/results equation for testing. Your basic point is that one
“should test everything”. I find this hard to swallow in a practical
world with only 24 hour days.
So what’s the point of testing if you’re not going to have 100% code
coverage through your tests? How are you going to prove your application
works? If one part of the application is not tested, then you can not
trust
the rest of your application.
Those who say “there’s not enough time to test,” from my experience,
haven’t
even given it a try, or want to but are still in the “code first, test
afterwards” mentality.
You NEED to write your tests first, THEN your code. It’s the only way
you
can be sure that all of your code is properly tested. And as for time,
it’s
a very simple change to project management. The typical, non-TDD project
timeline goes like this:
So yeah, the coding takes a little longer, but the final end-to-end
testing
is a VASTLY shorter time period, because you can prove the inner
workings of
your application, and if you write integration tests as well, you can
prove
interactivity is correct as well. In the end, projects are done faster,
more
bug-free, and with a better design and cleaner code.
Most noticeable issue is that you are not mocking out model methods in
functional tests and never mentioned mocks/stubs at all.
By the way, have you tried rspec? Once tried I’m addicted, despite of
lots of black magic, making it hard to trace down problems, if those
occured, it’s really really good.
Also, like most of tech writers does, you’re writing on testing from
technical standpoint, while some information on theoretical aspects
would make your article much more valuable.
Gregory,
Thank you for the article you posted on testing. I went through this
and your examples this morning and feel you could help people more if
you taught them the ‘rational’ that would help one find the right
coding/results equation for testing. Your basic point is that one
“should test everything”. I find this hard to swallow in a practical
world with only 24 hour days.
If you walk into an application mid way, maybe it’ll be tough to
immediately layer code in, that’s true. Also, when I first started
doing camping, I didn’t really have the time to mess around learning
mosquito (it’s test framework) in time for my first gig with it.
However, once you get into TDD/BDD, it becomes entirely possible to
write tests for everything, especially if you write them first.
If you treat them as part of the design process, you spend zero time
writing down things on paper and all the time writing the code. It’s
true, you need to have a lot of experience to make Test-First and Test-
Everything make sense for your development process. Still, it’s one
of the best skills I’ve picked up, and while I’ll be honest and say I
slip from time to time, usually my code with tests is surprisingly
written faster and has less issues than the code where I’ve left red
zones or not tested at all.
I’m not talking about slim margins, either. I’m estimating from my
past work, that the increase in productivity is anywhere from 50% to
200% better on any given job.
In terms of Ruport, our almost complete coverage for the core library
has been a tremendous safety net. Not everything was written test-
first, but the stuff that is came out better. That’s just my
experience. You might try it for a small project that you can take
the time to learn on, and see how it works for you.
Most noticeable issue is that you are not mocking out model methods in
functional tests and never mentioned mocks/stubs at all.
Yup, it was in my original outline but got cut due to article length
constraints
By the way, have you tried rspec? Once tried I’m addicted, despite of
lots of black magic, making it hard to trace down problems, if those
occured, it’s really really good.
Actually, I’m going to be doing a 3 part series on BDD for O’Reilly
towards the end of the summer. I’ve not been using it much in
practice, but we just swapped ruport-util’s tests to specs and will be
using it more in work, too. It seems worth investigating for sure.
Also, like most of tech writers does, you’re writing on testing from
technical standpoint, while some information on theoretical aspects
would make your article much more valuable.
Yes, that’s probably true. I think that I might expand the article
down the line, but I did consciously avoid theory in it, so I’m not
surprised you mentioned that. Next time around, I’ll try to at least
cite a few sources for those who want more background.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
I’ve not been using it much in