On 7/23/07, Obie F. [email protected] wrote:
- Are test-driven development (tdd) or behavior-driven development
(bdd) important aspects of your day-to-day practice? Did you pick up
tdd from your involvement with Rails or bring it with you from another
technology?
I’d like to say that we’re totally dedicated to TDD, but in practice
that hasn’t happened. However some of our most painful, annoying bugs
have resulted from “fixes” that weren’t test-driven. Once you slip up
here and there by just writing code, it becomes easier to justify
subsequent small changes without writing tests. But we all know about
code debt, broken windows, etc.
Personally, I’m in love with RSpec. When I started working for my new
company I was the only Ruby guy. Gradually two of the other fellows
have started writing Ruby code. They haven’t really been bitten by
the RSpec bug yet, but I think it’s just because they haven’t had time
to really get into it. One issue is that I work remotely so I don’t
get to show them the little tricks as much. I’m moving in a week
though so hopefully that’ll take care of that, and we’ll be a bunch of
RSpec-happy hackers.
- Is there palpable peer pressure in the Rails community to adopt
progressive testing practices such as tdd and bdd? (Or does that
strike you as Agilist hogwash?)
I don’t think there’s peer pressure, but TDD is certainly encouraged.
As you know, Rails puts a bunch of tests in place for you. It’s
really easy to write tests. You certainly don’t have to though.
That brings up a more interesting point (to me, anyway). There’s no
peer pressure to do anything in the Rails community. DHH picked a
language that made him happy. Rails was born from code that he felt
was beautiful. That kind of set the tone for the Rails community. So
much about Rails is subjective. People either “get it” or they don’t.
But there’s no malice from those who do towards those who don’t -
just gentle encouragement.
- On your production projects, do you monitor and strive towards
achieving 100% test-coverage? Why or why not? If you do keep track, do
you use the built-in rake task, RCov, or some other method of gauging
your code coverage?
We use RCov, but we don’t strive for 100% coverage. It’s just not
practical really. Also, we’ve come to rely on RSpec less as a
regression testing tool and more of a design tool. We can only be
confident in our code if all of our acceptance tests are running. We
use RSpec to prevent us from writing crappy code that we have to keep
running 
- Unit, Functional, Integration tests…? Selenium and Watir…? All
equally important in Rails? Or are some kinds of tests more important
and valuable to you than others?
I like to start with functional tests because it’s the fastest,
easiest way to discover the objects and APIs in the system. We end up
with a very tight, clean API that’s useful.
Unit tests are super important. They allow us to refactor the code
base and get instant feedback when something breaks (or needs to
change).
We use Selenium for the integration/acceptance tests. They’re kind of
a pain to run, but they exercise all the important use cases.
The functional and unit tests are all written in RSpec, and I use
autotest to keep an eye on things for me. The selenium test suite
runs nightly, but we can also kick it off on the testing server
whenever we have to. When using RSpec as a design tool, it can’t
catch all the regressions, so we need Selenium tests.
- Do you hate fixtures? Can I accurately say it is the Rails way to
hate (or at least complain about) fixtures? Do you make use of mocking
and stubbing instead? Mocha? Some combination?
I don’t hate them. For the most part I don’t use them though…as I
mentioned earlier, in functional tests I mock out all the AR stuff,
because I’m just trying to figure out the design. Fixtures can come
in handier for unit tests, actually. For example we needed to
generate several reports that used a bunch of complicated SQL. Any
time you’re writing custom SQL you definitely need to hit the database
to verify that your code actually works. Fixtures were perfect there
since we didn’t want a lot of setup code.
To me, fixtures should be used when the code base is small, and you
can use the functional tests as mini integration tests. They can get
messy though as the code base gets larger, and of course they can slow
things down.
I also think that larger code bases will benefit more from RSpec’s
design capabilities than its testing capabilities. This might be
because fixtures can get out of hand, but it may simply be a matter of
mindset - if you’re focus your energy on design, you’re more likely to
end up with a good one.
If you use mocks, you HAVE to have some external acceptance tests.
It’s nice to use RSpec to discover the interfaces in your system, but
at the end of the day you rely on an implementation. You have to have
something in place to verify that your implementation is still working
as expected.
Note that you should always have acceptance tests of some sort. I
just feel that functional tests that use fixtures (and thus the AR
implementation) count as an acceptance test. They’re just not good
for when your app gets big.
- Have you switched, or do you plan to switch over to RSpec for your
testing and specs? Is it important to you that I include some coverage
of RSpec in a book entitled “The Rails Way” or do you feel it would be
inappropriate?
Apparently I’ve been using RSpec for over a year now! [1]
I think you should definitely include it in there. I know a lot of
people look at RSpec and first think to themselves that it’s nothing
special, there’s no real point in learning it. However some really,
really sharp dudes (courtenay, topfunky) said that at the beginning
and have since admitted they just missed the beauty that is RSpec.
Again I think it’s probably a subjective thing…but if really smart
people are quick to dismiss it at the beginning, think of what the
rest of us would do. Maybe some of your readers won’t care, but I
think a lot more are going to get it and will love you for it.
I can honestly say that RSpec is the best thing about Rails coding.
Writing Rails apps is easy, it’s designing them well that’s hard.
RSpec is a great tool in that regard.
I wish someone would write a Ruby-based BDD book now
Your comments are greatly appreciated.
Wow that got long. Hope some of it is useful.
Pat