unit testing advice

[Phlip]

Just another follow-up (see also my earlier post, which addresses your
concerns directly): there's a new screencast at railscasts.com today,
on exactly that topic: models that are not ActiveRecord models. It's
here:

http://media.railscasts.com/videos/121_non_active_record_model.mov

I'm glad to see it, as this is something that people often don't
realize is possible, and when they do it can be quite a revelation.

It don't mean nothin' if you can't use the validators. We tried recently, and
could not get them working in a non-ActiveRecord model. After exceeding our
time-box, we simply made the model into an ActiveRecord table, with no records
in the database yet. It's speculative coding, because we will need to save the
records for our next iteration.

But, in theory, most of the validators have nothing to do with the persistence
itself, so the ActiveRecord maintainers could go decouple them...

 

[David A. Black]

Hi --

It don't mean nothin' if you can't use the validators. We tried recently, and
could not get them working in a non-ActiveRecord model. After exceeding our
time-box, we simply made the model into an ActiveRecord table, with no
records in the database yet. It's speculative coding, because we will need to
save the records for our next iteration.

But, in theory, most of the validators have nothing to do with the
persistence itself, so the ActiveRecord maintainers could go decouple them...

Couldn't you just write a #valid? method for the class, or something
like that? If we're talking about non-AR models, they're probably not
going to have #save or #update_attributes and so on, so you presumably
wouldn't be depending on a save-time validation suite. In other words,
what is the point in the life-cycle of the object that's analogous to
saving an AR object, and can't you intervene at that point?


David

 

[Phlip]

Couldn't you just write a #valid? method for the class, or something
like that?

Obviously yes but why should we have to? validates_presence_of :foo only needs
to peek at self.foo, so why should we have to rewrite it?

I'm not talking about the advanced stuff like :scope => ...

 

[David A. Black]

Hi --

Obviously yes but why should we have to? validates_presence_of :foo only
needs to peek at self.foo, so why should we have to rewrite it?

I think it's reasonable for ActiveRecord::Validations to be fairly
hard-wired to ActiveRecord, so it might just be less trouble in the
end to roll your own for non-AR classes. Or maybe write
ActiveSupport::Validations, which could be more general (and not get
into the create/update/save distinctions and all that).


David

 

[David Chelimsky]

The model generation just gives you a file with an empty class definition for
your tests, and I think something similar happens with RSpec. (Just to
clarify: I'm talking about model generation, not scaffold generation,
which does give you all sorts of tests and which I dislike strongly
and consider manifestly counter-productive.)

Hi David - I'm curious to know more about why you find this
counter-productive, if you wouldn't mind sharing.

Cheers,
David

 

[David A. Black]

Hi --

Hi David - I'm curious to know more about why you find this
counter-productive, if you wouldn't mind sharing.

Sorry -- I didn't spot this among the unread for some reason.

I don't want to go into depth since we're not in a Rails forum, but in
brief, it's my experience that the scaffolding neither provides a good
starting point for a production application (which I don't believe it
was ever intended to), nor serves as a good learning tool (which I
believe it is supposed to be). It's a one-trick pony, and there's much
too much of a history of people getting confused or stymied because
they assume that what the scaffolding does is somehow a "default" or
authoritative application skeleton.


David

 

[David Chelimsky]

Hi --



Sorry -- I didn't spot this among the unread for some reason.

I don't want to go into depth since we're not in a Rails forum, but in
brief, it's my experience that the scaffolding neither provides a good
starting point for a production application (which I don't believe it
was ever intended to), nor serves as a good learning tool (which I
believe it is supposed to be). It's a one-trick pony, and there's much
too much of a history of people getting confused or stymied because
they assume that what the scaffolding does is somehow a "default" or
authoritative application skeleton.

Hey David,

Thanks for the response. And here's my late response to yours for much
the same reason...

I understood your previous comment to mean you found the code examples
generated by rspec to be counter productive, but now I'm sensing its
actually the scaffolding.

Forgetting about rspec or rails, my take is that generated code is
just like your own code as far as the ruby runtime is concerned, and
that *if* you are using generated code and maintaining it, that it
should be accompanied by a robust set of generated tests.

Agree? Disagree?

Thanks for playing,
David

 

[Phlip]

Forgetting about rspec or rails, my take is that generated code is
just like your own code as far as the ruby runtime is concerned, and
that *if* you are using generated code and maintaining it, that it
should be accompanied by a robust set of generated tests.

Agree? Disagree?

Rails (you know - that web framework thingey) has a plugin that generates a
scaffold, with good tests, and then you play with the code to add your custom
features.

We were looking for a scaffold, and found this one had notes saying it was
"officially" deprecated on behalf of another scaffold.

That one you could not edit. It was a framework inside a framework, and you had
to research and apply every tweak to every (runaway) argument to their entry
points, just to change anything.

We went with the "obsolete" version of the scaffold. (-:

 

[David A. Black]

Hi --

Hey David,

Thanks for the response. And here's my late response to yours for much
the same reason...

I understood your previous comment to mean you found the code examples
generated by rspec to be counter productive, but now I'm sensing its
actually the scaffolding.

Yes, I meant the scaffolding.

Forgetting about rspec or rails, my take is that generated code is
just like your own code as far as the ruby runtime is concerned, and
that *if* you are using generated code and maintaining it, that it
should be accompanied by a robust set of generated tests.

Agree? Disagree?

It's an interesting question. I'm trying to puzzle through whether
there might ever be a case where you'd be generating code but
generating the tests for it was for some reason prohibitively more
difficult. I think that if not then it makes sense to generate tests.
Or do the tests sometimes themselves involve code generation? (Maybe
just dynamic code generation.)


David

--
Rails training from David A. Black and Ruby Power and Light:
Intro to Ruby on Rails January 12-15 Fort Lauderdale, FL
Advancing with Rails January 19-22 Fort Lauderdale, FL *
* Co-taught with Patrick Ewing!
See http://www.rubypal.com for details and updates!

 

[David Chelimsky]

Hi --



Yes, I meant the scaffolding.


It's an interesting question. I'm trying to puzzle through whether
there might ever be a case where you'd be generating code but
generating the tests for it was for some reason prohibitively more
difficult. I think that if not then it makes sense to generate tests.
Or do the tests sometimes themselves involve code generation? (Maybe
just dynamic code generation.)

I meant the question more generally, but in the case of the rspec
generators, they do generate tests using the same command line
arguments that rails uses generate the application code. So if you
generate a resource with a 'name' attribute, the generated tests for
the new and edit forms expect there to be a form with an input for
'name'.

render "/companies/new.html.erb"

response.should have_tag("form[action=?][method=post]", companies_path) do
with_tag("input#company_name[name=?]", "company[name]")
end

What's your gut reaction to that? "Too much"? "Oh, cool"? "Ewwwwww"? "Awesome"?

 

[David A. Black]

Hi --

Hi --



Yes, I meant the scaffolding.


It's an interesting question. I'm trying to puzzle through whether
there might ever be a case where you'd be generating code but
generating the tests for it was for some reason prohibitively more
difficult. I think that if not then it makes sense to generate tests.
Or do the tests sometimes themselves involve code generation? (Maybe
just dynamic code generation.)

I meant the question more generally, but in the case of the rspec
generators, they do generate tests using the same command line
arguments that rails uses generate the application code. So if you
generate a resource with a 'name' attribute, the generated tests for
the new and edit forms expect there to be a form with an input for
'name'.

render "/companies/new.html.erb"

response.should have_tag("form[action=?][method=post]", companies_path) do
with_tag("input#company_name[name=?]", "company[name]")
end

What's your gut reaction to that? "Too much"? "Oh, cool"? "Ewwwwww"? "Awesome"?

I have trouble getting past the concept of "generating a resource", at
least as reflected in Rails scaffolding and usage generally; see:

http://dablog.rubypal.com/2008/3/23/splitting-hairs-over-resource
http://dablog.rubypal.com/2008/4/24/splitting-hairs-over-resource-part-2

Having the test certainly makes sense if you've definitely decided
that the generated code is what you want. In this case I think for me
the problem is more in the underlying code generation step itself.


David

--
Rails training from David A. Black and Ruby Power and Light:
Intro to Ruby on Rails January 12-15 Fort Lauderdale, FL
Advancing with Rails January 19-22 Fort Lauderdale, FL *
* Co-taught with Patrick Ewing!
See http://www.rubypal.com for details and updates!

 

[David Chelimsky]

Hi --

Hi --

On Thu, 11 Sep 2008, David Chelimsky wrote:

Hi --

On Thu, 14 Aug 2008, David Chelimsky wrote:

The model generation just gives you a file with an empty class
definition
for
your tests, and I think something similar happens with RSpec. (Just
to
clarify: I'm talking about model generation, not scaffold generation,
which does give you all sorts of tests and which I dislike strongly
and consider manifestly counter-productive.)

Hi David - I'm curious to know more about why you find this
counter-productive, if you wouldn't mind sharing.

Sorry -- I didn't spot this among the unread for some reason.

I don't want to go into depth since we're not in a Rails forum, but in
brief, it's my experience that the scaffolding neither provides a good
starting point for a production application (which I don't believe it
was ever intended to), nor serves as a good learning tool (which I
believe it is supposed to be). It's a one-trick pony, and there's much
too much of a history of people getting confused or stymied because
they assume that what the scaffolding does is somehow a "default" or
authoritative application skeleton.

Hey David,

Thanks for the response. And here's my late response to yours for much
the same reason...

I understood your previous comment to mean you found the code examples
generated by rspec to be counter productive, but now I'm sensing its
actually the scaffolding.

Yes, I meant the scaffolding.

Forgetting about rspec or rails, my take is that generated code is
just like your own code as far as the ruby runtime is concerned, and
that *if* you are using generated code and maintaining it, that it
should be accompanied by a robust set of generated tests.

Agree? Disagree?

It's an interesting question. I'm trying to puzzle through whether
there might ever be a case where you'd be generating code but
generating the tests for it was for some reason prohibitively more
difficult. I think that if not then it makes sense to generate tests.
Or do the tests sometimes themselves involve code generation? (Maybe
just dynamic code generation.)

I meant the question more generally, but in the case of the rspec
generators, they do generate tests using the same command line
arguments that rails uses generate the application code. So if you
generate a resource with a 'name' attribute, the generated tests for
the new and edit forms expect there to be a form with an input for
'name'.

render "/companies/new.html.erb"

response.should have_tag("form[action=?][method=post]", companies_path) do
with_tag("input#company_name[name=?]", "company[name]")
end

What's your gut reaction to that? "Too much"? "Oh, cool"? "Ewwwwww"?
"Awesome"?

I have trouble getting past the concept of "generating a resource", at
least as reflected in Rails scaffolding and usage generally; see:

http://dablog.rubypal.com/2008/3/23/splitting-hairs-over-resource
http://dablog.rubypal.com/2008/4/24/splitting-hairs-over-resource-part-2

Thanks for those excellent posts. I confess that I have not yet read
Fielding's dissertation and you've piqued my interest. Although I had
to laugh when the link from your blog post
(http://www.ics.uci.edu/~fielding/pubs/dissertation/) led me to a
directory index rather than the resource (the dissertation) whose
representation I sought.

 

[David A. Black]

Hi --

Thanks for those excellent posts. I confess that I have not yet read
Fielding's dissertation and you've piqued my interest. Although I
had to laugh when the link from your blog post
(http://www.ics.uci.edu/~fielding/pubs/dissertation/) led me to a
directory index rather than the resource (the dissertation) whose
representation I sought.

I guess I should have tested it first


David

--
Rails training from David A. Black and Ruby Power and Light:
Intro to Ruby on Rails January 12-15 Fort Lauderdale, FL
Advancing with Rails January 19-22 Fort Lauderdale, FL *
* Co-taught with Patrick Ewing!
See http://www.rubypal.com for details and updates!