Isn't the idea of TDD and BDD that you discover what classes and method are needed by writing the tests first? So there *should* be no model in place prior to writing the test; the initial failure of the test is what drive the creation of the model.
When "greenfield" coding, one way to design is to force an unpredictable design to emerge via TDD. That's the high-end rationale for TDD. You can also sketch a design, then see if you can write the right tests to force it to emerge.
When writing new code that addresses some existing library or module, you often do this:
def test_learn_foo
foo = assemble_foo
result = foo.activate
p result
end
Now you noodle around inside foo.activate - essentially learning what it can do. Then you pin down your research with assertions. It's all good.
I certainly "get" the idea that it's better to write the tests first.
Unfortunately my dinosaur brain needed to write some code to prove
that my class model was workable...!
I often have to bootstrap myself into an application by getting
something running before I can get my brain into test mode. Certainly
with something like Rails, there's a lot to do before any tests are
written, since you can't write unit tests before you know what your
models are (and generating the model so conveniently writes the test
file for you
Isn't the idea of TDD and BDD that you discover what classes and method are needed by writing the tests first? So there *should* be no model in place prior to writing the test; the initial failure of the test is what drive the creation of the model.
That may be the ideal for some people, but not for me when I'm
modeling a domain and especially when I'm working out a database
schema. I don't consider unit tests to have superseded the other tools
that support those activities, including blank pieces of paper and
index cards and so on. I guess you could write unit tests for a Rails
app before creating the models, if you mocked up the objects'
attributes, their associated objects, and so on (since there would
presumably be no database yet), and then rename your files so they
don't get clobbered when you generate the test files... but it seems
like it would be terribly arduous, with no real gain, and I don't
think I've ever seen anyone do it.
One thing to remember is that TDD is about development, and that not
all instances of entering code on a keyboard are development. And
we've all, I believe, learned an absolute ton from exploration and
experimentation that wasn't part of the process of ongoing application
development. It's important not to feel like you're being
unprofessional or sloppy if you happen to want to try out some code in
a file, or in irb, and you don't write a test for it.
In fact, one question that has come to intrigue me recently is the
question of whether there are any active programmers who have
literally written code test-first from the time they first learned how
to program onward. I suspect the answer is no -- and if that's the
case, it means that there is no evidence for the position that it's
always, automatically bad to write code without a test.
Has anyone ever seen a Learn To Program or Learn Language Blub book that did TDD? I doubt such a thing exists. Instead, people are shown code, encouraged to write code, then (in so many words) told that what they were shown and told is not the right way to code. On the other hand, having a unit test for the 1-liner helloworld.rb seems massively goofy.
The thing is, all the people who argue that testing first is the right
way to code did not themselves learn to code that way. That doesn't
prove or disprove anything, but it does make me wonder whether
teaching someone test methodology right out of the starting gate is
demonstrably the best way to go about teaching someone programming. I
tend to think it isn't, though I also think that there are good and
bad ways to introduce testing into the mix (the best way probably
being to present it as essentially what they've been doing all along,
but more structured; and the worst way being the "OK, the fun is over,
now let's get serious" stuff).
David
···
On Sun, 3 Aug 2008, James Britt wrote:
On Sun, 3 Aug 2008, Shadowfirebird wrote:
--
Rails training from David A. Black and Ruby Power and Light:
* Advancing With Rails August 18-21 Edison, NJ
* Co-taught by D.A. Black and Erik Kastner
See http://www.rubypal.com for details and updates!
> David A. Black wrote:
>> In fact, one question that has come to intrigue me recently is the
>> question of whether there are any active programmers who have
>> literally written code test-first from the time they first learned how
>> to program onward. I suspect the answer is no -- and if that's the
>> case, it means that there is no evidence for the position that it's
>> always, automatically bad to write code without a test.
>
>
> Has anyone ever seen a Learn To Program or Learn Language Blub book that did
> TDD? I doubt such a thing exists. Instead, people are shown code,
> encouraged to write code, then (in so many words) told that what they were
> shown and told is not the right way to code. On the other hand, having a
> unit test for the 1-liner helloworld.rb seems massively goofy.
The thing is, all the people who argue that testing first is the right
way to code did not themselves learn to code that way. That doesn't
prove or disprove anything, but it does make me wonder whether
teaching someone test methodology right out of the starting gate is
demonstrably the best way to go about teaching someone programming. I
tend to think it isn't, though I also think that there are good and
bad ways to introduce testing into the mix (the best way probably
being to present it as essentially what they've been doing all along,
but more structured; and the worst way being the "OK, the fun is over,
now let's get serious" stuff).
I started on coding sheets. We wrote tests first. We used to
"desk check" our code too. We had to, it might take a couple of days to
get the cards punched before getting one, perhaps two, compilations per
day. I'm in my forties, so this is ancient, but not prehistoric history.
That said, I lean towards what David is saying, that it's a skill to be
learned after experimenting/playing with code. After all, we all learn
to speak before we write. And being able to write well takes a lot more
skill than simply being able to write what we say.
Isn't the idea of TDD and BDD that you discover what classes and method are needed by writing the tests first? So there *should* be no model in place prior to writing the test; the initial failure of the test is what drive the creation of the model.
That may be the ideal for some people, but not for me when I'm
modeling a domain and especially when I'm working out a database
schema. I don't consider unit tests to have superseded the other tools
that support those activities, including blank pieces of paper and
index cards and so on. I guess you could write unit tests for a Rails
app before creating the models, if you mocked up the objects'
attributes, their associated objects, and so on (since there would
presumably be no database yet), and then rename your files so they
don't get clobbered when you generate the test files... but it seems
like it would be terribly arduous, with no real gain, and I don't
think I've ever seen anyone do it.
Quote:
I guess you don't use the Rails code generation then.
Steven: No, not at all. I use TDD to generate code manually.
So you don't even do model generation with Rails?
Steven: Not at all. Especially when I'm pairing with somebody who's never used Rails before or who has never done TDD before I find it especially important not to rely on the generator to give me test stubs, to give me things that I should know or that I should be providing for myself. When the failings specifications tell me that I need it, because that would be contradicting what I'm trying to teach.
For almost my entire career people have assumed that I can look at
their code and tell what it is supposed to do. I can't; no-one can,
with any accuracy. All I can do is look at code and say what it
*does*. Which is probably not the same thing, or I wouldn't be
looking at the code in the first place...
But if there are automated tests, *they* will tell you what the code
should do. And, better yet, if the programmers have been using them,
they will be accurate and up to date. They might not be complete, of
course, but two out of three is a hell of a good hit rate in this
subject.
As far as I am concerned, that's good enough to spark a religious conversion.
As for test-driven-design, I think it's a fine ideal. Mostly when I
code I know in advance where I'm going, and in that case it pays to
use TDD. But sometimes I haven't the faintest idea what I'm doing; I
don't know how many classes I need or what jobs go in what classes --
or even if the idea is at all workable. I suspect that TDD isn't of
much use in those times.
Shadowfirebird.
···
On Sat, Aug 2, 2008 at 9:19 PM, marc <gmane@auxbuss.com> wrote:
David A. Black said...
On Sun, 3 Aug 2008, James Britt wrote:
> David A. Black wrote:
>> In fact, one question that has come to intrigue me recently is the
>> question of whether there are any active programmers who have
>> literally written code test-first from the time they first learned how
>> to program onward. I suspect the answer is no -- and if that's the
>> case, it means that there is no evidence for the position that it's
>> always, automatically bad to write code without a test.
>
>
> Has anyone ever seen a Learn To Program or Learn Language Blub book that did
> TDD? I doubt such a thing exists. Instead, people are shown code,
> encouraged to write code, then (in so many words) told that what they were
> shown and told is not the right way to code. On the other hand, having a
> unit test for the 1-liner helloworld.rb seems massively goofy.
The thing is, all the people who argue that testing first is the right
way to code did not themselves learn to code that way. That doesn't
prove or disprove anything, but it does make me wonder whether
teaching someone test methodology right out of the starting gate is
demonstrably the best way to go about teaching someone programming. I
tend to think it isn't, though I also think that there are good and
bad ways to introduce testing into the mix (the best way probably
being to present it as essentially what they've been doing all along,
but more structured; and the worst way being the "OK, the fun is over,
now let's get serious" stuff).
I started on coding sheets. We wrote tests first. We used to
"desk check" our code too. We had to, it might take a couple of days to
get the cards punched before getting one, perhaps two, compilations per
day. I'm in my forties, so this is ancient, but not prehistoric history.
That said, I lean towards what David is saying, that it's a skill to be
learned after experimenting/playing with code. After all, we all learn
to speak before we write. And being able to write well takes a lot more
skill than simply being able to write what we say.
--
Cheers,
Marc
--
Me, I imagine places that I have never seen / The colored lights in
fountains, blue and green / And I imagine places that I will never go
/ Behind these clouds that hang here dark and low
But it's there when I'm holding you / There when I'm sleeping too /
There when there's nothing left of me / Hanging out behind the
burned-out factories / Out of reach but leading me / Into the
beautiful sea
Isn't the idea of TDD and BDD that you discover what classes and method are needed by writing the tests first? So there *should* be no model in place prior to writing the test; the initial failure of the test is what drive the creation of the model.
That may be the ideal for some people, but not for me when I'm
modeling a domain and especially when I'm working out a database
schema. I don't consider unit tests to have superseded the other tools
that support those activities, including blank pieces of paper and
index cards and so on. I guess you could write unit tests for a Rails
app before creating the models, if you mocked up the objects'
attributes, their associated objects, and so on (since there would
presumably be no database yet), and then rename your files so they
don't get clobbered when you generate the test files... but it seems
like it would be terribly arduous, with no real gain, and I don't
think I've ever seen anyone do it.
I guess you don't use the Rails code generation then.
Steven: No, not at all. I use TDD to generate code manually.
So you don't even do model generation with Rails?
Steven: Not at all. Especially when I'm pairing with somebody who's never used Rails before or who has never done TDD before I find it especially important not to rely on the generator to give me test stubs, to give me things that I should know or that I should be providing for myself. When the failings specifications tell me that I need it, because that would be contradicting what I'm trying to teach.
OK, now I've seen one person I imagine there are more. Luckily we
don't need a consensus; we can all do what we're comfortable with.
It's interesting that Steve does it this way, and I'd like to see it
in person.
It doesn't appeal to me not to use the model generator. For one thing,
I assume that it would mean having to run sequential migrations, where
you wrote a test or spec that tested for the presence of, say, a
first_name attribute on the user; then add that column to the
database; then test for last_name; then add that column; and so forth.
I don't mean to sound like I'm parodying what Steve is describing. I
assume that this, or something like it, is what you'd end up doing.
I'm not sure what Steve means by test stubs in this context. 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.)
David
···
On Sun, 3 Aug 2008, James Britt wrote:
On Sun, 3 Aug 2008, James Britt wrote:
--
Rails training from David A. Black and Ruby Power and Light:
* Advancing With Rails August 18-21 Edison, NJ
* Co-taught by D.A. Black and Erik Kastner
See http://www.rubypal.com for details and updates!
I guess you don't use the Rails code generation then.
Steven: No, not at all. I use TDD to generate code manually.
So you don't even do model generation with Rails?
Steven: Not at all. Especially when I'm pairing with somebody who's never used Rails before or who has never done TDD before I find it especially important not to rely on the generator to give me test stubs, to give me things that I should know or that I should be providing for myself. When the failings specifications tell me that I need it, because that would be contradicting what I'm trying to teach.
I don't know if we are discussing the same thing. This Rails command...
script/generate model MyModel
...does not create "stubs". It creates all the files that back up a Model, including its my_model_test.rb and fixtures/my_models.yml files.
I can't imagine not using it, because all it saves you is a lot of rote typing. Writing a test that fails because "fixtures/my_models.yml" does not exist is not TDD, because that's not production code.
I often write a test that fails because MyModel does not exist yet, to start the cycle.
I think Dave and Steve are discussing some tool that reads Ruby classes and spits out stubbed test cases for each method.
Check out Test-Driven Development By Example by Kent Beck. It brought
my understanding of TDD to a new level.
Regards,
Michael Guterl
···
On Sat, Aug 2, 2008 at 5:17 PM, Shadowfirebird <shadowfirebird@gmail.com> wrote:
On Sat, Aug 2, 2008 at 9:19 PM, marc <gmane@auxbuss.com> wrote:
David A. Black said...
On Sun, 3 Aug 2008, James Britt wrote:
> David A. Black wrote:
>> In fact, one question that has come to intrigue me recently is the
>> question of whether there are any active programmers who have
>> literally written code test-first from the time they first learned how
>> to program onward. I suspect the answer is no -- and if that's the
>> case, it means that there is no evidence for the position that it's
>> always, automatically bad to write code without a test.
>
>
> Has anyone ever seen a Learn To Program or Learn Language Blub book that did
> TDD? I doubt such a thing exists. Instead, people are shown code,
> encouraged to write code, then (in so many words) told that what they were
> shown and told is not the right way to code. On the other hand, having a
> unit test for the 1-liner helloworld.rb seems massively goofy.
The thing is, all the people who argue that testing first is the right
way to code did not themselves learn to code that way. That doesn't
prove or disprove anything, but it does make me wonder whether
teaching someone test methodology right out of the starting gate is
demonstrably the best way to go about teaching someone programming. I
tend to think it isn't, though I also think that there are good and
bad ways to introduce testing into the mix (the best way probably
being to present it as essentially what they've been doing all along,
but more structured; and the worst way being the "OK, the fun is over,
now let's get serious" stuff).
I started on coding sheets. We wrote tests first. We used to
"desk check" our code too. We had to, it might take a couple of days to
get the cards punched before getting one, perhaps two, compilations per
day. I'm in my forties, so this is ancient, but not prehistoric history.
That said, I lean towards what David is saying, that it's a skill to be
learned after experimenting/playing with code. After all, we all learn
to speak before we write. And being able to write well takes a lot more
skill than simply being able to write what we say.
--
Cheers,
Marc
I wish I had learned this stuff ten years ago.
For almost my entire career people have assumed that I can look at
their code and tell what it is supposed to do. I can't; no-one can,
with any accuracy. All I can do is look at code and say what it
*does*. Which is probably not the same thing, or I wouldn't be
looking at the code in the first place...
But if there are automated tests, *they* will tell you what the code
should do. And, better yet, if the programmers have been using them,
they will be accurate and up to date. They might not be complete, of
course, but two out of three is a hell of a good hit rate in this
subject.
As far as I am concerned, that's good enough to spark a religious conversion.
As for test-driven-design, I think it's a fine ideal. Mostly when I
code I know in advance where I'm going, and in that case it pays to
use TDD. But sometimes I haven't the faintest idea what I'm doing; I
don't know how many classes I need or what jobs go in what classes --
or even if the idea is at all workable. I suspect that TDD isn't of
much use in those times.
It doesn't appeal to me not to use the model generator. For one thing,
I assume that it would mean having to run sequential migrations, where
you wrote a test or spec that tested for the presence of, say, a
first_name attribute on the user; then add that column to the
database; then test for last_name; then add that column; and so forth.
I don't mean to sound like I'm parodying what Steve is describing. I
assume that this, or something like it, is what you'd end up doing.
Parenthetically, you are "allowed" to edit a pre-existing migration file, if you can keep track of which VERSION your production database has.
Within that loop, yes, write a test that fails because MyModel has no has_many NotherModel, then pass it by adding a column :nother_model_id to the migration.
I don't know if we are discussing the same thing. This Rails command...
script/generate model MyModel
...does not create "stubs". It creates all the files that back up a Model, including its my_model_test.rb and fixtures/my_models.yml files.
That's exactly what is being talked about.
And the issue is that it creates a model file before the developer has written a failing test indicating the need for a model file.
One might assume that the developer is going to end up in the same place anyways, so the code might as well be automatically generated, but it's contrary to "write the spec, have it fail, then write the code to make the spec pass".
I'm not arguing in favor of dogmatic testing practices, justing pointing out that there is at least one person who actually walks the walk.
(Besides, when a developer selects Rails as their toolkit they've already made many code choices long before there are any tests to drive those decisions, so the TDD/BDD purity thing is sort of a moot point.)
Hi David - I'm curious to know more about why you find this
counter-productive, if you wouldn't mind sharing.
Cheers,
David
···
On Sun, Aug 3, 2008 at 7:20 AM, David A. Black <dblack@rubypal.com> 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.)
It doesn't appeal to me not to use the model generator. For one thing,
I assume that it would mean having to run sequential migrations, where
you wrote a test or spec that tested for the presence of, say, a
first_name attribute on the user; then add that column to the
database; then test for last_name; then add that column; and so forth.
I don't mean to sound like I'm parodying what Steve is describing. I
assume that this, or something like it, is what you'd end up doing.
Parenthetically, you are "allowed" to edit a pre-existing migration file, if you can keep track of which VERSION your production database has.
Yes, but then you get into migrating backwards, which I increasingly
think is almost never appropriate. (Though not quite never, maybe.)
Within that loop, yes, write a test that fails because MyModel has no has_many NotherModel, then pass it by adding a column :nother_model_id to the migration.
I'm afraid I don't see the advantage of that, at least in every case,
over bootstrapping at least part of a database schema and model
structure first. Certainly the kind of thing you're describing does
happen, but if I'm creating an Order model and I know that it's going
to belong to Customer, I'm not averse to saying so up front. Also,
with a large table, you could get into an awful lot of migrations.
It all comes out in the wash, so to speak, since once the project is
bootstrapped in some way, the different approaches to bootstrapping
tend to converge.
David
···
On Sun, 3 Aug 2008, Phlip wrote:
--
Rails training from David A. Black and Ruby Power and Light:
* Advancing With Rails August 18-21 Edison, NJ
* Co-taught by D.A. Black and Erik Kastner
See http://www.rubypal.com for details and updates!
I don't know if we are discussing the same thing. This Rails command...
script/generate model MyModel
...does not create "stubs". It creates all the files that back up a Model, including its my_model_test.rb and fixtures/my_models.yml files.
That's exactly what is being talked about.
And the issue is that it creates a model file before the developer has written a failing test indicating the need for a model file.
One might assume that the developer is going to end up in the same place anyways, so the code might as well be automatically generated, but it's contrary to "write the spec, have it fail, then write the code to make the spec pass".
I'm not arguing in favor of dogmatic testing practices, justing pointing out that there is at least one person who actually walks the walk.
(Besides, when a developer selects Rails as their toolkit they've already made many code choices long before there are any tests to drive those decisions, so the TDD/BDD purity thing is sort of a moot point.)
I don't think anything in Rails militates against a test-driven
approach, though -- in fact, by creating test files for you, and
having the default 'rake' command be to run your tests, it creates a
very hospitable environment for testing. If you don't write tests,
you're always reminded of their (non)existence by the presence of the
files.
David
···
On Mon, 4 Aug 2008, James Britt wrote:
--
Rails training from David A. Black and Ruby Power and Light:
* Advancing With Rails August 18-21 Edison, NJ
* Co-taught by D.A. Black and Erik Kastner
See http://www.rubypal.com for details and updates!
Yeah, I think this is a good example of the dogma getting in the way of common sense. To use Rails and not allow it to generate files and by extension satisfy it's own conventions for you just sounds silly to me.
My opinion is that the goal of testing is to add some degree of protection to the software you build, not to straight-jacket you as a programmer.
James Edward Gray II
···
On Aug 3, 2008, at 12:03 PM, James Britt wrote:
And the issue is that it creates a model file before the developer has written a failing test indicating the need for a model file.
One might assume that the developer is going to end up in the same place anyways, so the code might as well be automatically generated, but it's contrary to "write the spec, have it fail, then write the code to make the spec pass".
I'm not arguing in favor of dogmatic testing practices, justing pointing out that there is at least one person who actually walks the walk.
(Besides, when a developer selects Rails as their toolkit they've already made many code choices long before there are any tests to drive those decisions, so the TDD/BDD purity thing is sort of a moot point.)
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.
David
···
On Thu, 14 Aug 2008, David Chelimsky wrote:
On Sun, Aug 3, 2008 at 7:20 AM, David A. Black <dblack@rubypal.com> wrote:
--
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
See http://www.rubypal.com for details and updates!
I'm not arguing in favor of dogmatic testing practices, justing pointing out that there is at least one person who actually walks the walk.
(Besides, when a developer selects Rails as their toolkit they've already made many code choices long before there are any tests to drive those decisions, so the TDD/BDD purity thing is sort of a moot point.)
Yeah, I think this is a good example of the dogma getting in the way of common sense. To use Rails and not allow it to generate files and by extension satisfy it's own conventions for you just sounds silly to me.
My opinion is that the goal of testing is to add some degree of protection to the software you build, not to straight-jacket you as a programmer.
I've been wondering about resistance to "purist" TDD/BDD, and if there's some aspect of "listen to your body" to observe. For example, when exercising or dieting, there are assorted rules or regimes to follow, but if something is hurting, or if you've constant cravings for some food or another, then maybe that's an important sign to deviate from the original plan, and not simply a lack of will power or a failure to "do it right."
Rather than people applying ad hoc approaches to Test-second Development, maybe there are some better practices to be shared for what seems to be a common situation.
Well, I'm not a professional Ruby developer, but I *am* someone that
writes code for a living, and I've been an IT contractor.
And while I love the idea of TDD, if I were using it professionally
then I simply wouldn't be able to afford to be that dogmatic. Even if
I always, always, wrote the tests first, sooner or later I would run
up against code written by somewhere else who didn't -- and as a
contractor, of course, I never got to choose what programming and
testing methodologies were being used at all. ("You want me to indent
every other line by four tabs? Okay, you're paying.")
I'm not criticising anyone for being gung-ho about DTT; I would simply
advise everyone to learn how to write tests second, as well.
Shadowfirebird.
···
On Sun, Aug 3, 2008 at 9:38 PM, Phlip <phlip2005@gmail.com> wrote:
James Britt wrote:
That's exactly what is being talked about.
And the issue is that it creates a model file before the developer has
written a failing test indicating the need for a model file.
So write the failing test, then run script/generate. Manually writing all
the files that script/generate creates is just heroism.
--
Me, I imagine places that I have never seen / The colored lights in
fountains, blue and green / And I imagine places that I will never go
/ Behind these clouds that hang here dark and low
But it's there when I'm holding you / There when I'm sleeping too /
There when there's nothing left of me / Hanging out behind the
burned-out factories / Out of reach but leading me / Into the
beautiful sea
I've seen a lot of Rails coders completely lose track of the fact that
"Model" means "Domain Model" because of thinking like that. To the
point of getting confused when you start talking about models that
don't derive from ActiveRecord::Base. They've begun to identify
"Model" with "table in the database" rather than "model of a domain
entity".
I challenge any Rails developer to start a a web app without a
database, leaving persistence for iteration 2. It can be an
eye-opening experience, forcing you to think more about domain
concerns and less about keeping MySQL happy.
···
On Sun, Aug 3, 2008 at 2:23 PM, David A. Black <dblack@rubypal.com> wrote:
I'm afraid I don't see the advantage of that, at least in every case,
over bootstrapping at least part of a database schema and model
structure first. Certainly the kind of thing you're describing does
happen, but if I'm creating an Order model and I know that it's going
to belong to Customer, I'm not averse to saying so up front. Also,
with a large table, you could get into an awful lot of migrations.
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
···
On Sat, Aug 23, 2008 at 6:24 PM, David A. Black <dblack@rubypal.com> wrote:
Hi --
On Thu, 14 Aug 2008, David Chelimsky wrote:
On Sun, Aug 3, 2008 at 7:20 AM, David A. Black <dblack@rubypal.com> 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.
