I think the answer is: if you have to ask, then you should use them
Otherwise, don’t use them when you feel confident that you don’t need
them.
Or use them, but don’t knock yourself out trying to keep them perfect
with total isolation and all data interactions mocked. I’m writing
controller specs now hitting the real models instead of mocks, setting
expectations on method calls only in specific examples to test them.
I’m finding I’m much more productive on specs now and my blood
pressure is lower.
Controller specs are a good thing. Controllers are the heart of your
application. The heart may be a simple muscle, but your doctor will
still tell you it ought to be tested. It’s not hard to test either,
unless you insist on building a delicate network of veins and arteries
outside your body to simulate the ones inside it. I don’t believe the
heart needs to be removed to prove it’s working.
I forgot to add that until there is a new way to handle the role that
controllers currently are responsible for, I would probably teach
someone
how to write good controllers and controller examples. I would also
allow
them to experience the pain that comes with trying to write bloated
controller actions and filters so they can see the warning signs that
come
with the controller specs. This facilitates reflection and discussion,
and
allows them to grow while I’m there.
More generally, as a teacher we have a lot of experience and reference
points that we draw on. It can be easy to overlook this and to just have
everyone do what we do, but then they never get the “why” part of it
because
that’s still up in our heads.
Zach
Nope, I’m trying to teach RSpec/BDD to an organization that currently
doesn’t use it and has 0% test coverage. It’s interesting, to say the
least. They’re good devs, but even so, the effects of not writing tests
first (or even at all) are painfully evident when trying to get the
codebase under test, and especially to change stuff. Really puts your
“working effectively with legacy code” chops to work
On Wed, Oct 29, 2008 at 6:02 PM, aslak hellesoy [email protected]wrote:
logic, you can write acceptance tests that give you confidence that
I think the nay from Pat was conditional, as it should be.
edge case, make a judgement on where the right abstraction level is to
test it. That may be controller, view, model or somewhere else.
“working effectively with legacy code” chops to work
This reminds me of an argument I was going to make for consistently
writing specs as you go, even for apparently very simple controllers.
As the controller gets more and more complex, it’s hard to know when
you’ve crossed the line into something that needs specs, and when you
realise it, it’s usually too late.
codebase under test, and especially to change stuff. Really puts your
“working effectively with legacy code” chops to work
This reminds me of an argument I was going to make for consistently writing
specs as you go, even for apparently very simple controllers. As the
controller gets more and more complex, it’s hard to know when you’ve crossed
the line into something that needs specs, and when you realise it, it’s
usually too late.
I’d agree with this (in spite of my previous comments), and add to it.
One of the benefits of writing examples is that they actually help to
expose things that are growing complex. If it’s hard to test, it’s
probably hard to change.
Aslak made a good point earlier this thread with “don’t write specs
just cuz,” but perhaps this fact is sufficient “cuz” to motivate.
Aslak made a good point earlier this thread with “don’t write specs
just cuz,” but perhaps this fact is sufficient “cuz” to motivate.
WDYT?
There’s something else here (nothing to do with testing rails
controllers, but testing in general) about the psychological blockage
to working up the testing infrastructure in order to test something
you’ve never tested before. It’s so easy and tempting to say ‘sod it’
and dive into code & fix when you can’t muster the mental energy to
work out how to make something testable. By sticking to the TDD
mindset in quite an uncharacteristically dogmatic way, unless I’m
doing a throwaway spike, I find I usually get just enough discipline
to get me through that blockage, and out into the bright sunshine of
the TDD superhighway.
first (or even at all) are painfully evident when trying to get the
the line into something that needs specs, and when you realise it, it’s
WDYT?
I think having this motivation and/or reasoning makes it no longer a
“just
cuz” argument. There is a clear reason Matt is writing the spec. It
seems to
be in alignment with Ben M.'s argument earlier. There is design value
from these specs, it just isn’t prevalent in at the time of creation.
Instead the value is received as the application evolves and grows
because
you’re able to maintain a clean and simple design – partially from the
early warning signs that the examples give you.
testable. By sticking to the TDD mindset in quite an uncharacteristically
dogmatic way, unless I’m doing a throwaway spike, I find I usually get just
enough discipline to get me through that blockage, and out into the bright
sunshine of the TDD superhighway.
first (or even at all) are painfully evident when trying to get the
I’d agree with this (in spite of my previous comments), and add to it.
One of the benefits of writing examples is that they actually help to
expose things that are growing complex. If it’s hard to test, it’s
probably hard to change.
Aslak made a good point earlier this thread with “don’t write specs
just cuz,” but perhaps this fact is sufficient “cuz” to motivate.
WDYT?
eh I dunno. I mean, I completely agree that hard-to-write tests often
expose bad code. But there isn’t any gray area when it comes to
designing Rails controllers, in my opinion. I see an action that’s more
than five lines long and I know it’s wrong. I don’t need to write
examples to tell me that.
That said, when teaching someone I suppose it would make sense to use
examples to illustrate that, at least until they develop an aesthetic
appreciation as finely tuned as my own
I’d agree with this (in spite of my previous comments), and add to it.
One of the benefits of writing examples is that they actually help to
expose things that are growing complex. If it’s hard to test, it’s
probably hard to change.
Aslak made a good point earlier this thread with “don’t write specs
just cuz,” but perhaps this fact is sufficient “cuz” to motivate.
Hmm, I just tried to map the benefit you get from specs in three key
areas:
(read as eg
Specs very helpful for Good Design)
Specs | No specs
Good Design very helpful for discourages
Documentation somewhat help[1] no effect on[2]
Regression Testing marginally help[3] no effect on[2]
[1] but Cucumber is better?
[2] given Cucumber features and simple controllers
[3] they don’t detect most real breakages
Just my opinion of course. But makes me think that David is right to
ask “Is it true we should write controller specs cuz they highlight
excess complexity?” I personally think that’s the only way they
provide real value, given they are at the surface of the app and
therefore hit directly by Cucumber.
But then, the longer I do BDD, the smaller my all classes have become,
and the more the value of unit specs have shifted from regression
testing to design. (I’m starting to think I need more RSpec mini-
integration examples, rather than doing everything on a class-by-class
basis.) So maybe the conclusion above is not controller-specific at
all.
I pushed around some stuff that I think should be in the model. The
other thing that I thought, but didn’t change (I don’t really know what
you’re doing with this action) is these render_to_string calls. Maybe
you have a good reason for it, but I would just do regular “render
:partial…” calls in the view.
you’re doing with this action) is these render_to_string calls. Maybe
you have a good reason for it, but I would just do regular “render
:partial…” calls in the view.
Pat
Thanks for taking a look, Pat. Much appreciated!
-Nick
eh I dunno. I mean, I completely agree that hard-to-write tests often
expose bad code. But there isn’t any gray area when it comes to
designing Rails controllers, in my opinion. I see an action that’s
more
than five lines long and I know it’s wrong. I don’t need to write
examples to tell me that.
