rspec users - Sep 2008 - RSpec makes me want to write better code

Hi,

Today is a big day. I officially transitioned from manually testing by
clicking around in my app, to automated testing with RSpec + Autotest.

Yes RSpec made me find a few weaknesses in my app: while I was writing
specs for one of my models, I discovered that I had forgotten some
validations, that simply I had never tested by my super manual clicking
workflow.

Also, RSpec made me discover something else: my model has some custom
find methods. Often over time I find myself changing the name of these
custom find  methods, e.g: find_all_products -> find_available_products

As some of these finds are used by more than 1 controller, changing the
name of the find_ often breaks code in different places at once. This
was painful to manually test, and it is still a bit painful to have
RSpec test, as I would also have to rename the custom find method in my
specs.

Based on this recent article:
http://www.matthewpaulmoore.com/articles/1276-ruby-on-rails-code-quality-checklist
"Each controller action only calls one model method other than an
initial find or new.".

Would this mean that I should change my custom find naming convention to
something more general that would never have to be renamed over time
such as find_for_index, find_for_create, etc?

What are your thoughts on that. Is there a "design pattern" on naming
custom find methods in Rails models? Because I tend to be seeing one.

Also, is it clever to write specs such as:
--
Product.respond_to? :find_for_index
--
so that if I break the rule of my naming convention, one of my spec will
quickly bark at me.


Best regards,
-- 
Posted via http://www.ruby-forum.com/.

On Thu, Sep 25, 2008 at 8:01 AM, Fernando Perez <lists at
ruby-forum.com>wrote:
>
> Also, RSpec made me discover something else: my model has some custom
> find methods. Often over time I find myself changing the name of these
> custom find  methods, e.g: find_all_products -> find_available_products
>
> As some of these finds are used by more than 1 controller, changing the
> name of the find_ often breaks code in different places at once. This
> was painful to manually test, and it is still a bit painful to have
> RSpec test, as I would also have to rename the custom find method in my
> specs.

Didn''t find_all_products do something different from
find_available_products? If so, it''s not really a renaming issue, as
far as
I can see. You''re changing behavior, therefore you change the specs.

> Based on this recent article:
>
>
http://www.matthewpaulmoore.com/articles/1276-ruby-on-rails-code-quality-checklist
> "Each controller action only calls one model method other than an
> initial find or new.".

I didn''t get that article (or, rather, that particular subarticle) at
all.
It sounded to me like some of the virulent REST advocates who want to
shoe-horn every action into an HTTP verb. The controller should do what the
controller needs to do. If that means displaying just available products
instead of all products, it should do that "with intention," not just
as the
default find action. That said, scopes can and should be defined, but
that''s
a well-understood idiom of Rails programming and can lead to abuse.

Would this mean that I should change my custom find naming convention to
> something more general that would never have to be renamed over time
> such as find_for_index, find_for_create, etc?

That puts too much controller knowledge in the model, in my opinion.

> Also, is it clever to write specs such as:
> --
> Product.respond_to? :find_for_index
> --
> so that if I break the rule of my naming convention, one of my spec will
> quickly bark at me.
>
I don''t think it really matters whether Product has a find_for_index
method
in and of itself. What matters is that the desired behavior, possibly
including and/or implemented by calling find_for_index, is achieved. If such
a naming convention was very important to the project, then a spec like that
would be appropriate. However, I''d regard it as a code smell if I saw
such a
test.

I can imagine other opinions on this subject and am eager to hear them.

///ark
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20080925/793ceb1a/attachment-0001.html>

On 25 Sep 2008, at 17:48, Mark Wilden wrote:
> "Each controller action only calls one model method other than an
> initial find or new.".
>
> I didn''t get that article (or, rather, that particular subarticle)
> at all.
I kinda tuned out when I read, "Polymorphic associations, however, are  
encouraged!"

I wouldn''t let that guy near a CSV file of my shopping list after  
reading that...

> It sounded to me like some of the virulent REST advocates who want  
> to shoe-horn every action into an HTTP verb. The controller should  
> do what the controller needs to do. If that means displaying just  
> available products instead of all products, it should do that "with  
> intention," not just as the default find action.
Is a better rule "each controller action should contain no more than  
two branches"? (But then, I try to apply that to all methods, and even  
then, I try to push conditional code as far down as possible.)

> That said, scopes can and should be defined, but that''s a well- 
> understood idiom of Rails programming and can lead to abuse.
>
> Would this mean that I should change my custom find naming  
> convention to
> something more general that would never have to be renamed over time
> such as find_for_index, find_for_create, etc?
>
> That puts too much controller knowledge in the model, in my opinion.
I''d try identify the problem that is being solved in the controller.   
*Why* does ProductController#index need that certain subset of the  
data?  Maybe the model method should be something like:

* Product.top_selling
* Product.not_selling
* Product.needs_updating

Does this better express the intent?
> What matters is that the desired behavior, possibly including and/or  
> implemented by calling find_for_index, is achieved. If such a naming  
> convention was very important to the project, then a spec like that  
> would be appropriate. However, I''d regard it as a code smell if I
> saw such a test.
I agree (I think).  Conventions decrease the mental effort to make  
something work at the risk of reduced insight.  Certainly if you are  
automatically checking that the code is following conventions, that  
suggests the convention is artificial and unnatural.  You could end up  
trying to map all the business problems onto a very crude technical  
interface.

Ashley


-- 
http://www.patchspace.co.uk/
http://aviewfromafar.net/

On 26 Sep 2008, at 12:31, Ashley Moran wrote:
>
> On 25 Sep 2008, at 17:48, Mark Wilden wrote:
>
>> "Each controller action only calls one model method other than an
>> initial find or new.".
>>
>> I didn''t get that article[1] (or, rather, that particular  
>> subarticle) at all.
>
> I kinda tuned out when I read, "Polymorphic associations, however,  
> are encouraged!"
Would you mind elaborating on why you don''t like these? I''m
pretty
new to rails (but not programming generally) and rather naive about  
such things!

Also why is the article so down on STI? What are the drawbacks? What  
do people use instead?

[1]http://www.matthewpaulmoore.com/articles/1276-ruby-on-rails-code- 
quality-checklist

cheers,
Matt
----
http://blog.mattwynne.net
http://songkick.com

In case you wondered: The opinions expressed in this email are my own  
and do not necessarily reflect the views of any former, current or  
future employers of mine.

On Fri, Sep 26, 2008 at 4:49 AM, Matt Wynne <matt at mattwynne.net> wrote:
>
> Also why is the article so down on STI? What are the drawbacks? What do
> people use instead?
>
I think the guy is really just down on inheritance itself, which is not an
unusual nor even entirely unjustified attitude. Ruby has far less need to
use inheritance because of the ability to mix in modules. And using it,
particularly beyond two levels deep, can most definitely lead to nightmarish
code, where changing one line in a parent class can make you spend an hour
(or a day) trying to figure out how to handle the repercussions to every
child class.

But I do believe that where a true "is-a" relationship exists,
inheritance
is often the best approach. I''m working on a program right now that has
a
Task class and an Appointment subclass. An Appointment (in this context) is
simply a Task that can only be performed on one day. Otherwise it''s
exactly
like a Task (again, in the context of my program). That''s an
"is-a"
relationship that inheritance was designed for, and it''s working quite
well.
And, as an agile practitioner, if I find that this relationship changes I
would throw out this class hierarchy.

STI is just a way to map inheritance to the database. I used it before I
knew what it was called. If you do use inheritance with models, I think
it''s
the best Rails way to persist the data.

Hmmm. Just realized that all this has nothing to do with RSpec....

///ark
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20080926/a87af03e/attachment-0001.html>

On Fri, Sep 26, 2008 at 4:31 AM, Ashley Moran <ashley.moran at
patchspace.co.uk
> wrote:
>
> Is a better rule "each controller action should contain no more than
two
> branches"? (But then, I try to apply that to all methods, and even
then, I
> try to push conditional code as far down as possible.)
>
On an OOP mailing list, a guy asserted that there shouldn''t be two
for-loops
in the same method. It sounded ridiculous to me at the time, but after ten
years of mulling it over, I believe he was right. :)

///ark
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20080926/7a7264eb/attachment.html>

On 26 Sep 2008, at 12:49, Matt Wynne wrote:
> Would you mind elaborating on why you don''t like these?
I''m pretty
> new to rails (but not programming generally) and rather naive about  
> such things!
It''s quite hard to explain briefly, but basically it makes the  
predicate (interpretation of the table) extremely difficult.

A normal table like

  cars
   ---------
   reg_plate
   owner_id
   purchase_date

Could be interpreted as "The car with reg plate <reg_plate> was
bought
by the person with ID <owner_id> on <purchase_date>" (ok, they
might
have sold it since, but...)

However, from the Rails wiki[1]:

  addresses
   ---------
   street
   city
   country
   addressable_id
   addressable_type # <- is a string

How do you interpret this?  The relationship is fundamentally  
different depending on the value of addressable_type, and is much  
harder to enforce as an integrity constraint*.

There''s another angle you can take, based on data types - you can  
define a type PERSON_ID for the attribute ''owner_id'' (and
re-use it in
the ''departments'' table as ''manager_id''),
but the type of
''addressable_id'' depends on the value of
''addressable_type''.  How can
a value not know its own type?

Easier solution:

  people
   ---------
   name
   delivery_address_id
   billing_address_id

"The person called <name> wants items delivered to the address with
ID
<delivery_address_id> and invoices delivered to the address with ID  
<billing_address_id>".


> Also why is the article so down on STI? What are the drawbacks? What  
> do people use instead?
>
>
[1]http://www.matthewpaulmoore.com/articles/1276-ruby-on-rails-code-quality-checklist
I''ll reply to Mark...

TBC

Ashley

[1] http://wiki.rubyonrails.org/rails/pages/UnderstandingPolymorphicAssociations

* pah, who needs their data integrity protected anyway?

-- 
http://www.patchspace.co.uk/
http://aviewfromafar.net/

On 26 Sep 2008, at 15:16, Mark Wilden wrote:
> Also why is the article so down on STI? What are the drawbacks? What  
> do people use instead?
One downside to STI is it forces you to leave NULL columns for  
attributes that don''t exist in all models.  This is also really bad  
for integrity.  I once started a CTI[1] extension to AR[2][3].  A lot  
of users were interested in it, but I got no response from the core  
team.

There''s talk on doing it in DataMapper too.  If I get some free time I
might look at it, but it''s a fairly complex bit of ORM work.  (I did  
want to write an ORM but I spend way too much time doing paid work...)

> I think the guy is really just down on inheritance itself, which is  
> not an unusual nor even entirely unjustified attitude. Ruby has far  
> less need to use inheritance because of the ability to mix in modules.
>
> ...
>
> But I do believe that where a true "is-a" relationship exists,  
> inheritance is often the best approach. I''m working on a program  
> right now that has a Task class and an Appointment subclass. An  
> Appointment (in this context) is simply a Task that can only be  
> performed on one day. Otherwise it''s exactly like a Task (again,
in
> the context of my program). That''s an "is-a"
relationship that
> inheritance was designed for, and it''s working quite well. And, as
> an agile practitioner, if I find that this relationship changes I  
> would throw out this class hierarchy.
That sounds like a perfect example.  I assume any code that works for  
"Task" will happily process an appointment.

> STI is just a way to map inheritance to the database. I used it  
> before I knew what it was called. If you do use inheritance with  
> models, I think it''s the best Rails way to persist the data.
Not the best possible way (which is CTI), but yeah, the best way you  
can do it with Rails (ActiveRecord).  It''s still a data modelling/ 
integrity headache, but not on the same level as polymorphic  
associations.

Ashley


[1] http://martinfowler.com/eaaCatalog/classTableInheritance.html
[2] http://dev.rubyonrails.org/ticket/6566
[3] http://aviewfromafar.net/2008/1/19/class-table-inheritance-in-activerecord
[4] http://wm.lighthouseapp.com/projects/4819/tickets/53-class-table-inheritance

([3] was started on my old employer''s blog, but they never maintained  
it after I left)


-- 
http://www.patchspace.co.uk/
http://aviewfromafar.net/

On Fri, Sep 26, 2008 at 8:28 AM, Ashley Moran <ashley.moran at
patchspace.co.uk
> wrote:
> One downside to STI is it forces you to leave NULL columns for attributes
> that don''t exist in all models.  This is also really bad for
integrity.
>
I think all of your comments make sense, but I did just want to call out
that "the Rails way" is not typically concerned with this sort of
integrity
at the database level. It''s handled in the model.

Whether that''s a good or bad thing can be debated, but it does explain
why
STI''s drawbacks don''t outweigh its strengths (primarily speed,
compared to
CTI, because of the lack of joins) in the minds of true Rails believers.

///ark
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20080926/1eafcd88/attachment.html>

On 26 Sep 2008, at 17:28, Mark Wilden wrote:
> I think all of your comments make sense, but I did just want to call  
> out that "the Rails way" is not typically concerned with this
sort
> of integrity at the database level. It''s handled in the model.
Ah ok, I wasn''t sure if your comment was intended to be neutral.   
You''re right, the Rails way is not concerned with DB-level integrity.
> Whether that''s a good or bad thing can be debated, but it does  
> explain why STI''s drawbacks don''t outweigh its strengths
(primarily
> speed, compared to CTI, because of the lack of joins) in the minds  
> of true Rails believers.
I''ve avoided STI unless the models share all the attributes (and  
therefore you .  But it can be used acceptably at a Ruby level (be  
sure to spec what attributes your classes have if you''re scared of  
pollution!) - it just means more hassle if you work in the DB directly.

Ashley

-- 
http://www.patchspace.co.uk/
http://aviewfromafar.net/

On Fri, Sep 26, 2008 at 9:47 AM, Ashley Moran <ashley.moran at
patchspace.co.uk
> wrote:
> (be sure to spec what attributes your classes have if you''re
scared of
> pollution!)
>
As part of the TDD process, I spec all attributes, but this doesn''t
seem
universal. Is this a misconception? Do people actually make sure that all
columns exist and can be written to and read from?

///ark
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20080926/28f4c232/attachment.html>

On Sep 26, 2008, at 1:18 PM, Mark Wilden wrote:
> On Fri, Sep 26, 2008 at 9:47 AM, Ashley Moran <ashley.moran at
patchspace.co.uk
> > wrote:
>
> (be sure to spec what attributes your classes have if you''re
scared
> of pollution!)
>
> As part of the TDD process, I spec all attributes, but this
doesn''t
> seem universal. Is this a misconception? Do people actually make  
> sure that all columns exist and can be written to and read from?
>
I usually end up doing something like this:

   columns = [:email, :message]
   columns.each do |column|
     it "should have a reader and writer for the column #{column}" do
       @invite.should respond_to(column)
       @invite.should respond_to("#{column}=")
     end
   end

Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20080926/1bd163ad/attachment.html>

On Fri, Sep 26, 2008 at 10:24 AM, Scott Taylor <
mailing_lists at railsnewbie.com> wrote:

> I usually end up doing something like this:
>
>   columns = [:email, :message]
>   columns.each do |column|
>     it "should have a reader and writer for the column #{column}"
do
>       @invite.should respond_to(column)
>       @invite.should respond_to("#{column}=")
>     end
>   end
>
That looks like a really good way to do this - thanks! Beyond that, as they
say, you''re testing ActiveRecord.

///ark
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20080926/a79411cf/attachment.html>

"Mark Wilden" <mark at mwilden.com> writes:
> On Fri, Sep 26, 2008 at 4:49 AM, Matt Wynne <span
dir="ltr"><mailto:matt at mattwynne.net></span> wrote:
>
> Also why is the article so down on STI? What are the drawbacks? What
> do people use instead?I think the guy is really just down on
> inheritance itself, which is not an unusual nor even entirely
> unjustified attitude. Ruby has far less need to use inheritance
> because of the ability to mix in modules. And using it, particularly
> beyond two levels deep, can most definitely lead to nightmarish code,
> where changing one line in a parent class can make you spend an hour
> (or a day) trying to figure out how to handle the repercussions to
> every child class.  But I do believe that where a true "is-a"
> relationship exists, inheritance is often the best approach. I&#39;m
> working on a program right now that has a Task class and an
> Appointment subclass. An Appointment (in this context) is simply a
> Task that can only be performed on one day. Otherwise it&#39;s exactly
> like a Task (again, in the context of my program). That&#39;s an
> "is-a" relationship that inheritance was designed for, and
it&#39;s
> working quite well. And, as an agile practitioner, if I find that this
> relationship changes I would throw out this class hierarchy.  STI is
> just a way to map inheritance to the database. I used it before I knew
> what it was called. If you do use inheritance with models, I think
> it&#39;s the best Rails way to persist the data.  Hmmm. Just realized
> that all this has nothing to do with RSpec....///ark
> _______________________________________________ rspec-users mailing
> list rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
fwiw, my inclination would still be to model this with composition
rather than inheritance :) An Appointment in the simplest case is just a
DateTime, but you can imagine it having a Location, Participants, and of
course a Task.  If it can have a Task, it can probably have multiple
Tasks.  And you can imagine Task evolving independently of Appointment,
for example a composite Task, or tasks requiring follow-up tasks under
certain conditions.  You can say YAGNI of course, but I think by
splitting those out entirely, you gain a more flexible model without
introducing complexity, and you avoid the technical stickiness that
accompanies STI in Rails.

And I think it''s perfectly acceptable to talk about OOD because design
is one of the key benefits of BDD :)

Pat

On Fri, Sep 26, 2008 at 11:46 AM, Pat Maddox <pergesu at gmail.com> wrote:
> "Mark Wilden" <mark at mwilden.com> writes:
>
> > Task class and an
> > Appointment subclass. An Appointment (in this context) is simply a
> > Task that can only be performed on one day. Otherwise it&#39;s
exactly
> > like a Task (again, in the context of my program).

> fwiw, my inclination would still be to model this with composition
> rather than inheritance :) An Appointment in the simplest case is just a
> DateTime, but you can imagine it having a Location, Participants, and of
> course a Task.

It could have all those things, but it doesn''t. :) The program is a
Getting
Things Done-type task manager (called giterdone). It couldn''t care less
who
the appointment is with. It just knows that an Appointment is something that
needs to "get done." The appointment''s location is handled by
a GTD context,
just like any other Task. The only difference is that this kind of Task can
only be done on a particular day. If you don''t giterdone on that day,
it
falls off the schedule.

  If it can have a Task, it can probably have multiple
> Tasks.  And you can imagine Task evolving independently of Appointment,
> for example a composite Task, or tasks requiring follow-up tasks under
> certain conditions.

A Project is another kind of Task - a sibling to Appointment - and can have
multiple Tasks (including Appointments). This again is in line with the GTD
philosophy, which draws a clear distinction between things with "next
actions" and things without (like a project).

You can say YAGNI of course, but I think by
> splitting those out entirely, you gain a more flexible model without
> introducing complexity, and you avoid the technical stickiness that
> accompanies STI in Rails.

Well, I do say YAGNI. Or at least YPAGNI. And again, if this turns out to be
incorrect, I''ll change it. I really do believe in trying the simplest
thing
that could possibly work. I''ve used STI on another side project of mine
(a
magic trick database, called abracadata), and it actually did work pretty
damn perfectly. But if it turns out to be the wrong decision, I''ll
embrace
that change.

However, I do admit that I''m biased in favor of inheritance where it
applies
- I''ve been using it since 1989, after all. Prior to that time, I was
implementing it in C before I knew what it was called. I really like the
idea of "this thing is like that thing except for one little
difference."

On the other hand, I have been bitten by using inheritance where composition
would have been a better design. I think the last time that happened was in
1991. :)

 And I think it''s perfectly acceptable to talk about OOD because design
> is one of the key benefits of BDD :)
>
Coolness.

///ark
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20080926/57817a3c/attachment.html>

On Sep 26, 2008, at 6:18 pm, Mark Wilden wrote:
> As part of the TDD process, I spec all attributes, but this
doesn''t
> seem universal. Is this a misconception? Do people actually make  
> sure that all columns exist and can be written to and read from?
What I meant by this was that say you have classes...

Animal {weight, height, dob}
Pet < Animal {name}
ZooAnimal < Animal {cage_id}

then, using ActiveRecord, all three will have attributes {weight,  
height, dob, name, cage_id}.  If you don''t want your pets in a cage,  
it''s worth preventing that and writing specs for it.

That''s what I was getting at, really - the extra data corruption
issues.

Ashley




-- 
http://www.patchspace.co.uk/
http://aviewfromafar.net/

On Fri, Sep 26, 2008 at 12:18 PM, Mark Wilden <mark at mwilden.com>
wrote:
> On Fri, Sep 26, 2008 at 9:47 AM, Ashley Moran
> <ashley.moran at patchspace.co.uk> wrote:
>
>>
>> (be sure to spec what attributes your classes have if you''re
scared of
>> pollution!)
>
> As part of the TDD process, I spec all attributes, but this
doesn''t seem
> universal. Is this a misconception? Do people actually make sure that all
> columns exist and can be written to and read from?
To me, spec''ing attributes is a red flag. It is not always a bad thing
or wrong, but it suggests that the focus is on structure instead of
behaviour and results in a lot of unnecessary overhead in your code
examples, making them more brittle and more difficult to maintain.

For example, let''s say we''ve got a Person model who can be old
enough
to vote or not. I might start w/ a code example like this:

person = Person.new(:birthdate => 17.years.ago)
person.should_not be_voting_age

Then I''d do the following:

* run the example and discover that Person doesn''t have a birthdate=
method
* add and run a migration that adds birthdate
* run the example and discover that Person doesn''t have a voting_age?
method
* def voting_age?; false; end
* run the example and it passes
* add another example for the positive case
* etc, etc

In that process, adding and running the migration was the
implementation step. No need to spec the existence of the field
directly, because this example will fail without it. And the failure
message will be that the the Person doesn''t respond to birthdate=, so
it''s exactly the feedback I''d want because it would point me
right to
the problem.

That all make sense?

Now sometimes there will be some up-front modeling discussions and you
may have a sense that a model needs a specific set of fields just
because that''s what the customer says. In those cases, I''d
recommend
trying to find something about the object''s behaviour to rationalize
the presence of those fields.

Developer: why do we care about having a birthdate field?
Customer: because I want to know how old people are.
Developer: why? How will you find out?
Customer: we''ll want to run demographics reports
Developer: why?
Customer: they''ll help us sell advertising

OK, so now we have a feature, Demographics Reports, that warrants the
presence of a birthdate field, and it is in THAT context that the
birthdate field should come into existence.

Hope this all helps.

Cheers,
David
> ///ark
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On Fri, Sep 26, 2008 at 3:10 PM, David Chelimsky <dchelimsky at
gmail.com>wrote:
>
> Now sometimes there will be some up-front modeling discussions and you
> may have a sense that a model needs a specific set of fields just
> because that''s what the customer says. In those cases,
I''d recommend
> trying to find something about the object''s behaviour to
rationalize
> the presence of those fields.
>
I think I know what you mean, and I would reply with two points, one agile,
and one not so agile:

1) In a test-driven environment, you don''t write code until you write a
failing test. Now, unless you mean to spread your table definition across
multiple migrations, that means you would have to write a spec for
Demographics Reports before you could create your table. By testing
attributes directly, you can indeed write a failing spec, then make it pass
by writing a migration. It''s not a huge deal, because you could indeed
write
multiple migrations as you define clients of the data.

2) The second is more important, however, and has to do with the non-agile
nature of databases. Put simply, you can''t change database content like
you
can change code. The example I used to use (probably outdated now) is fax
number. If you''re writing a customer relationship management system,
you
might want to store customer fax numbers _even if you have no use for them_.
The reason is simply that if you _do_ need them later, you can''t go
back and
get them. In other words, databases can have a prophecy requirement that
ever-malleable code does not.

All that said, I think your developer''s conversation with the customer
is
very apt. In many if not most cases, if there''s no output for the data,
there''s no need for its input. But not always.

///ark
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20080926/55f06256/attachment.html>

On Fri, Sep 26, 2008 at 5:38 PM, Mark Wilden <mark at mwilden.com>
wrote:
> On Fri, Sep 26, 2008 at 3:10 PM, David Chelimsky <dchelimsky at
gmail.com>
> wrote:
>>
>> Now sometimes there will be some up-front modeling discussions and you
>> may have a sense that a model needs a specific set of fields just
>> because that''s what the customer says. In those cases,
I''d recommend
>> trying to find something about the object''s behaviour to
rationalize
>> the presence of those fields.
>
> I think I know what you mean, and I would reply with two points, one agile,
> and one not so agile:
> 1) In a test-driven environment, you don''t write code until you
write a
> failing test. Now, unless you mean to spread your table definition across
> multiple migrations, that means you would have to write a spec for
> Demographics Reports before you could create your table. By testing
> attributes directly, you can indeed write a failing spec, then make it pass
> by writing a migration. It''s not a huge deal, because you could
indeed write
> multiple migrations as you define clients of the data.
This is really a deficiency of ActiveRecord migrations in my view.
DataMapper, for example, offers auto-migrations. You just add a
property to your model file and it takes care of the migration for
you. Of course, the way it does this is to drop the table and re-write
it, so you don''t want to do THAT in production :) But for agile dev,
it''s a much nicer process.
> 2) The second is more important, however, and has to do with the non-agile
> nature of databases. Put simply, you can''t change database content
like you
> can change code. The example I used to use (probably outdated now) is fax
> number. If you''re writing a customer relationship management
system, you
> might want to store customer fax numbers _even if you have no use for
them_.
> The reason is simply that if you _do_ need them later, you can''t
go back and
> get them. In other words, databases can have a prophecy requirement that
> ever-malleable code does not.
<soapbox>
I flatly disagree with this. Data is not inherently non-agile. But
some processes for managing the evolution of data are.

If you don''t need it now, or can''t even justify the need for
it in the
future, then it doesn''t belong in the code OR in the data. If somebody
thinks "we might need it later" then it should be discussed as a
requirement and either introduced as one or dropped. If "we might need
it later" then probably somebody has a good argument why. If nobody
can think of a good reason, then why add the extra weight to the db
AND to the examples. Not to mention the fact that fax numbers are
going to need some sort of format validation, which is going to be
code that costs money to write and maintain.
</soapbox>
> All that said, I think your developer''s conversation with the
customer is
> very apt. In many if not most cases, if there''s no output for the
data,
> there''s no need for its input. But not always.
I would agree with "but not always." But, I''d say that in the
"not
always" exceptions there should be a huge red flag and serious
discussion about why requirements are being imposed on a system for
which nobody can argue business value.

FWIW,
David
> ///ark

On Fri, Sep 26, 2008 at 4:16 PM, David Chelimsky <dchelimsky at
gmail.com>wrote:

> DataMapper, for example, offers auto-migrations. You just add a
> property to your model file and it takes care of the migration for
> you.

The relationship between schema and models in Rails is weird. The basic
source of truth for a model''s attributes is the database. But the
database
is defined in Ruby. I don''t know DataMapper, but it sounds as if it
puts the
responsibility in one place - the Ruby code.

> If you don''t need it now, or can''t even justify the need
for it in the
> future, then it doesn''t belong in the code OR in the data.

So you would not collect fax numbers in this scenario. That''s fine, but
if
you do need them later, you''re completely, absolutely, 100% screwed.
Kent''s
white book relied on the assumption that change is possible. But data
collection is an area where change is not possible, so I don''t think
agile
principles apply to it (necessarily).

You might well ask, "how far do you go in collecting currently useless
data?" And that would be a good question. :) I would answer that it would
have to be decided by experience in dealing with business requirements, but
not completely by whether there is a current need for it.

If somebody
> thinks "we might need it later" then it should be discussed as a
> requirement and either introduced as one or dropped. If "we might need
> it later" then probably somebody has a good argument why.

Even with a good argument, "we might need it later" is unYAGNIsh.

If nobody
> can think of a good reason, then why add the extra weight to the db
> AND to the examples.

Again, because you''ve only got one chance to get that data.

there should be a huge red flag and serious
> discussion about why requirements are being imposed on a system for
> which nobody can argue business value.
>
Agreed, absolutely.

///ark
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20080926/cf5ff68e/attachment.html>

On Fri, Sep 26, 2008 at 6:47 PM, Mark Wilden <mark at mwilden.com>
wrote:
> On Fri, Sep 26, 2008 at 4:16 PM, David Chelimsky <dchelimsky at
gmail.com>
> wrote:
>
>>
>> DataMapper, for example, offers auto-migrations. You just add a
>> property to your model file and it takes care of the migration for
>> you.
>
> The relationship between schema and models in Rails is weird. The basic
> source of truth for a model''s attributes is the database. But the
database
> is defined in Ruby. I don''t know DataMapper, but it sounds as if
it puts the
> responsibility in one place - the Ruby code.
A little rails history:

Before migrations data was defined only in sql. The argument for this
was that it was DRY to only define the data in one place. The result
was myriad comments in everybody''s model files duplicating the schema
because they didn''t want to have to look in two places to understand a
model.

Enter migrations, which move data definitions to Ruby. Yay! Their in
Ruby. Except now they are STILL in another place :)

Now putting the attributes in the model as DataMapper and Og do comes
with its own problems. AFAIK, deploys for either require migrations
developed in sql. Nothing for free :)
>
>>
>> If you don''t need it now, or can''t even justify the
need for it in the
>> future, then it doesn''t belong in the code OR in the data.
>
> So you would not collect fax numbers in this scenario. That''s
fine, but if
> you do need them later, you''re completely, absolutely, 100%
screwed. Kent''s
> white book relied on the assumption that change is possible. But data
> collection is an area where change is not possible, so I don''t
think agile
> principles apply to it (necessarily).
> You might well ask, "how far do you go in collecting currently useless
> data?" And that would be a good question. :) I would answer that it
would
> have to be decided by experience in dealing with business requirements, but
> not completely by whether there is a current need for it.
Again - "If you don''t need it now, or can''t even justify
the need for
it in the future." If a customer wants it, then they should be able to
tell you why. If they can''t and they still want it, then you might
have to give it to them if you want to get paid, but the conversation
is important.

Conversely, if you "know" from experience that the customer is going
to need it, then you should be able to rationalize that for them in
terms of business value.
>> If somebody
>> thinks "we might need it later" then it should be discussed
as a
>> requirement and either introduced as one or dropped. If "we might
need
>> it later" then probably somebody has a good argument why.
>
> Even with a good argument, "we might need it later" is unYAGNIsh.
YAGNI is a guideline, not a law. In practice, it doesn''t mean
"don''t
ever do stuff you don''t need right now" - it means anything being
imposed right now that isn''t needed right now imposes a risk that it
will never be used, and the costs of that risk should be considered
when making the decision include or exclude a given feature or, in the
context of our discussion, data field.

If that cost is understood and a decision is made to include a
feature/data field anyhow because the perceived benefits outweigh the
perceived costs, then so be it.
>> If nobody
>> can think of a good reason, then why add the extra weight to the db
>> AND to the examples.
>
> Again, because you''ve only got one chance to get that data.
Ah, I misunderstood that you were talking about data *collection*. I
agree that data collection brings up a lot of different questions, but
I still believe that any fields that we''re adding now that we
don''t
have a need for now should only be added after first seriously
exploring what the need might be and with a clear understanding of the
maintenance costs. Not to mention the impact on users who might
divulge information. If you can''t rationalize why you need my fax
number, why in hell would I supply it? And if you ask me for 10 things
you don''t really need, my interest in filling out the form decreases.
>>
>> there should be a huge red flag and serious
>> discussion about why requirements are being imposed on a system for
>> which nobody can argue business value.
>
> Agreed, absolutely.
Thank god we agree!

Seriously - thanks for the convo. This is good stuff.

Cheers,
David
> ///ark

I must say, I quite enjoyed that conversation. You guys (David and  
Mark) both have some very good points, and it was great to see another  
discussion about client interaction. Thanks guys!

On 26 Sep 2008, at 17:28, Mark Wilden wrote:
> On Fri, Sep 26, 2008 at 8:28 AM, Ashley Moran  
> <ashley.moran at patchspace.co.uk> wrote:
>
> One downside to STI is it forces you to leave NULL columns for  
> attributes that don''t exist in all models.  This is also really
bad
> for integrity.
>
> I think all of your comments make sense, but I did just want to  
> call out that "the Rails way" is not typically concerned with
this
> sort of integrity at the database level. It''s handled in the
model.
I wouldn''t call this the ''rails way'' particularly - I
think it''s more
of a general OO design philosophy that says the database is just an  
implementation detail. I have gradually moved, over the years, from  
feeling like the database needed to be the foundation of my whole  
domain (and therefore have tight integrity rules etc) to wishing it  
would just go away and stop bothering me. I like the way ORMs let me  
work in code most of my day rather than having to drop into the  
database to find out what the rules are.

cheers,
Matt
----
http://blog.mattwynne.net
http://songkick.com

In case you wondered: The opinions expressed in this email are my own  
and do not necessarily reflect the views of any former, current or  
future employers of mine.



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20080927/6fd4aaaf/attachment.html>

Hi all,

does anyone have any tips or examples on how to run specs programmatically?
I''d like to manually
load some example groups, then perhaps reflect on their describes and its, and
then execute them
and get back a Ruby object which I can interrogate for the results.

thanks
Dan

2008/9/26 David Chelimsky <dchelimsky at gmail.com>
> On Fri, Sep 26, 2008 at 12:18 PM, Mark Wilden <mark at mwilden.com>
wrote:
> > On Fri, Sep 26, 2008 at 9:47 AM, Ashley Moran
> > <ashley.moran at patchspace.co.uk> wrote:
> >
>
> To me, spec''ing attributes is a red flag. It is not always a bad
thing
> or wrong, but it suggests that the focus is on structure instead of
> behaviour

What David said. A lot.

It seems these conversations come up time and again because Rails overloads
the idea of "model". In a Rails app the model serves as both your
domain
model and your persistence strategy, because of the coupling inherent in the
Active Record pattern. Your domain model should evolve out of solving
problems in your domain. For any non-trivial domain model the persistence
strategy should be an entirely separate concern.

At the risk of going off on one, Active Record scales to *exactly zero
behaviour* in your model. In other words it is perfect for
data-on-the-screen apps, which to be fair is about 90% of web apps. As soon
as your domain model becomes sufficiently interesting it becomes a contest
between us and the AR pixies. Luckily we have the likes of David and Pat
Maddox on our side :)

If you start by specifying what you want your application to do in the form
of a single user example (a scenario), the model should fall out of solving
this. Unfortunately this doesn''t fit the model-driven (generators)
approach
that Rails encourages.

I''m not sure what advice to offer here, other than to be aware that
Rails
"best practices" are usually counter to an outside-in,
behaviour-driven
approach to writing applications. So if you want to use all the code-gen
magic in Rails you will always be making these trade-offs.

Cheers,
Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20080927/4b4f2407/attachment.html>

On Sat, Sep 27, 2008 at 11:26 AM, Dan North <tastapod at gmail.com> wrote:

It seems these conversations come up time and again because Rails
overloads
> the idea of "model". In a Rails app the model serves as both your
domain
> model and your persistence strategy, because of the coupling inherent in
the
> Active Record pattern.
>
Interesting. This coupling actually brought me to one of my first
"a-ha!"
moment in Rails (similar to when I first learned about the ++ operator in
C). Finally, I thought, I don''t have to do anything to set up the
butt-simple relationships between models and tables that are found (as you
say) in 90% of web apps (and other applications, too). Rails allows models
as complicated as you want, and it also allows you to do work in the
database when you need to (I know "find_by_sql" is a dirty word, but
it
allows me to perform pivots on multiple tables of millions of rows, where AR
simply could not handle the SQL). But it makes the overwhelmingly common
case simple, and I like that.

So I''ve found that this model-db coupling to be a powerful feature of
Rails.
I know it''s saved me a lot of work, because I''ve had to do it
manually so
many other times in the last 25 years. If it''s not sufficient or
appropriate
in any particular case, I don''t have to use it.

I know this view puts me on the wrong side of the contest you speak of
(which I frankly didn''t even know I''d entered). And yes, using
Rails the way
I (and many others) do involves trade-offs. But the one trade-off it
doesn''t
require is with TSTTCPW, which is the guiding philosophy in everything I do.

I guess this makes me an AR pixie. :)

///ark
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20080927/de002fa4/attachment.html>

On Sat, Sep 27, 2008 at 2:29 PM, Mark Wilden <mark at mwilden.com>
wrote:
> On Sat, Sep 27, 2008 at 11:26 AM, Dan North <tastapod at gmail.com>
wrote:
>
>> It seems these conversations come up time and again because Rails
>> overloads the idea of "model". In a Rails app the model
serves as both your
>> domain model and your persistence strategy, because of the coupling
inherent
>> in the Active Record pattern.
>
> Interesting. This coupling actually brought me to one of my first
"a-ha!"
> moment in Rails (similar to when I first learned about the ++ operator in
> C). Finally, I thought, I don''t have to do anything to set up the
> butt-simple relationships between models and tables that are found (as you
> say) in 90% of web apps (and other applications, too). Rails allows models
> as complicated as you want, and it also allows you to do work in the
> database when you need to (I know "find_by_sql" is a dirty word,
but it
> allows me to perform pivots on multiple tables of millions of rows, where
AR
> simply could not handle the SQL). But it makes the overwhelmingly common
> case simple, and I like that.
> So I''ve found that this model-db coupling to be a powerful feature
of Rails.
> I know it''s saved me a lot of work, because I''ve had to
do it manually so
> many other times in the last 25 years. If it''s not sufficient or
appropriate
> in any particular case, I don''t have to use it.
> I know this view puts me on the wrong side of the contest you speak of
> (which I frankly didn''t even know I''d entered). And yes,
using Rails the way
> I (and many others) do involves trade-offs. But the one trade-off it
doesn''t
> require is with TSTTCPW, which is the guiding philosophy in everything I
do.
> I guess this makes me an AR pixie. :)
I *think* Dan means underlying magic code when he uses the word pixie.
> ///ark
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On Sat, Sep 27, 2008 at 1:32 PM, David Chelimsky <dchelimsky at
gmail.com>wrote:
> On Sat, Sep 27, 2008 at 2:29 PM, Mark Wilden <mark at mwilden.com>
wrote:
>
> > I guess this makes me an AR pixie. :)
>
> I *think* Dan means underlying magic code when he uses the word pixie.
>
Oh. Right.

Never mind. :)

///ark
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20080927/d1cf3976/attachment.html>

On Sat, Sep 27, 2008 at 10:32 PM, David Chelimsky <dchelimsky at
gmail.com> wrote:
> On Sat, Sep 27, 2008 at 2:29 PM, Mark Wilden <mark at mwilden.com>
wrote:
>> On Sat, Sep 27, 2008 at 11:26 AM, Dan North <tastapod at
gmail.com> wrote:
>>
>>> It seems these conversations come up time and again because Rails
>>> overloads the idea of "model". In a Rails app the model
serves as both your
>>> domain model and your persistence strategy, because of the coupling
inherent
>>> in the Active Record pattern.
>>
>> Interesting. This coupling actually brought me to one of my first
"a-ha!"
>> moment in Rails (similar to when I first learned about the ++ operator
in
>> C). Finally, I thought, I don''t have to do anything to set up
the
>> butt-simple relationships between models and tables that are found (as
you
>> say) in 90% of web apps (and other applications, too). Rails allows
models
>> as complicated as you want, and it also allows you to do work in the
>> database when you need to (I know "find_by_sql" is a dirty
word, but it
>> allows me to perform pivots on multiple tables of millions of rows,
where AR
>> simply could not handle the SQL). But it makes the overwhelmingly
common
>> case simple, and I like that.
>> So I''ve found that this model-db coupling to be a powerful
feature of Rails.
>> I know it''s saved me a lot of work, because I''ve had
to do it manually so
>> many other times in the last 25 years. If it''s not sufficient
or appropriate
>> in any particular case, I don''t have to use it.
>> I know this view puts me on the wrong side of the contest you speak of
>> (which I frankly didn''t even know I''d entered). And
yes, using Rails the way
>> I (and many others) do involves trade-offs. But the one trade-off it
doesn''t
>> require is with TSTTCPW, which is the guiding philosophy in everything
I do.
>> I guess this makes me an AR pixie. :)
>
> I *think* Dan means underlying magic code when he uses the word pixie.
>
Dan always says pixies for stuff he doesn''t understand. They
don''t
have pixies in England I think.

Aslak
>> ///ark
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On Sep 27, 2008, at 12:16 am, David Chelimsky wrote:
> This is really a deficiency of ActiveRecord migrations in my view.
> DataMapper, for example, offers auto-migrations. You just add a
> property to your model file and it takes care of the migration for
> you. Of course, the way it does this is to drop the table and re-write
> it, so you don''t want to do THAT in production :) But for agile
dev,
> it''s a much nicer process.

Static migrations are essential, I think.  Without them, you can''t  
have repeatability.  But auto migrations are cool for playing around  
with stuff.  Hobo migrations[1] nails it.  You define the attributes  
in the model class, and it compares your models and development  
database to generate static migration files.

Unfortunately Hobo is very tied to Rails and AR.  But DataMapper  
already tracks attributes, so I wonder how hard it''d be to port...

Ashley


[1] http://hobocentral.net/hobofields/


-- 
http://www.patchspace.co.uk/
http://aviewfromafar.net/

On Sep 27, 2008, at 9:17 am, Matt Wynne wrote:
> I wouldn''t call this the ''rails way''
particularly - I think it''s
> more of a general OO design philosophy that says the database is  
> just an implementation detail. I have gradually moved, over the  
> years, from feeling like the database needed to be the foundation of  
> my whole domain (and therefore have tight integrity rules etc) to  
> wishing it would just go away and stop bothering me. I like the way  
> ORMs let me work in code most of my day rather than having to drop  
> into the database to find out what the rules are.
Matt,

I agree with you - to am extent.  The thing is, with a full suite of  
stories (that work through the public interface) your *entire app* is  
an implementation detail.

<aside type="anecdote">
The other day I was going over some example code with a client.  I  
prepared it for a user stories + Cucumber + Celerity talk/workshop,  
although I don''t think I''ll need it now.  It was a crude one- 
controller CRUD (well CR, anyway) app written in Ramaze, for  
simplicity.  The plan was to build a fuller Merb app to build on  
later.  The only reason I was going to switch to Merb was because this  
client is considering it, and was more than happy when I suggested  
doing some research on it on my time.  But I knew this could raise the  
issue "the first one was a prototype, and Ramaze is a prototyping  
framework".  Even more so because the data store was this:

   class EventsController < Ramaze::Controller
     EVENTS = [ ]

     # ...

     def create
       EVENTS << request[:event_name]
     end
   end

Which led us on to a discussion about what exactly *is* a prototype,  
and what is a primitive production app.  (I''ve had to pull the slides  
for this, I think it''d be a talk on itself.)  So I said,
"Hmmmmmmm,
how long *would* it take to port to Merb?"  Not wanting to let our  
coffee go cold, I set to it... and 10 mins later, five of which was  
faffing around working out the differences between Ramaze and Merb  
controllers, it was running.  Indeed, Cucumber told us so before I  
loaded the page in a browser, as it implemented this:

Feature: Event creation
   So that Potential Delegates know an Event is happening
   As an Organiser
   I want to create Events

   # ...

   Scenario: Multiple event creation
     GivenScenario Successful Event creation
     Given I am on the Event creation page
     When I submit valid Event details for event ''My Second
Event''
     Then the Events index page should show ''List of events''
     And it should show ''My Second Event''
     And it should show ''My First Event''
     And it should not show ''No events, please come back
later''

Eventually my client decided that, on the basis that I evolved the  
code rather than throwing it away and re-writing it, that it was  
actually a primitive production app.  And it stores the data in an  
array in the controller.  More surprisingly, he decided that - on the  
basis it has no runnable specs - his own 2-year-old app serving  
several clients is a prototype!
</aside>

So anyway, my point is, if you disparage the database on the premise  
it''s an implementation detail, you should apply equally little concern
to every other part of the app.

The reality I''ve found is that you find uses and insight in data long  
after you initially decided how to model it - possibly long after you  
stopped maintaining your app.  And I''ve been in the situation of  
having to unravel garbage and data corruption because someone didn''t  
enforce DB integrity.

I think every component of an app should receive the same attention to  
quality.  It''s impossible to know where an edge case will sneak past  
and bite you, so you have to cover as much as possible.

(Sorry if that was even rantier than usual - but I have a thing for  
data quality!!!)

Ashley


-- 
http://www.patchspace.co.uk/
http://aviewfromafar.net/

On Sat, Sep 27, 2008 at 5:04 PM, Ashley Moran <ashley.moran at
patchspace.co.uk
> wrote:
> The thing is, with a full suite of stories (that work through the public
> interface) your *entire app* is an implementation detail.
>
Yep. I would go further and say that, at the end of the day, the only
interface that matters is the user interface. If a user sees (no matter how
indirectly) the same behavior, it doesn''t matter whether
there''s a database
on the other end or a herd of monkeys typing randomly into terminals.

Given that (the primacy of user experience), the database can be of immense
importance to the app - far more than just a means of saving state so you
don''t have to type everything in again each time you log in to the
application. It doesn''t matter if you''ve behavior-driven your
development to
the nth degree if a report isn''t available in an acceptable amount of
time.
Maybe for 50% of web apps (SWAG), you never need to think about this. But
for apps that deal with millions of rows, the database (and the queries
against it) may be the single most important "implementation detail"
there
is.

///ark
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20080927/28bf09f2/attachment.html>

We do have pixies! They do all the "magic" stuff.

How else do you think it happens?

;)


2008/9/27 aslak hellesoy <aslak.hellesoy at gmail.com>
> On Sat, Sep 27, 2008 at 10:32 PM, David Chelimsky <dchelimsky at
gmail.com>
> wrote:
> > On Sat, Sep 27, 2008 at 2:29 PM, Mark Wilden <mark at
mwilden.com> wrote:
> >> On Sat, Sep 27, 2008 at 11:26 AM, Dan North <tastapod at
gmail.com> wrote:
> >>
> >>> It seems these conversations come up time and again because
Rails
> >>> overloads the idea of "model". In a Rails app the
model serves as both
> your
> >>> domain model and your persistence strategy, because of the
coupling
> inherent
> >>> in the Active Record pattern.
> >>
> >> Interesting. This coupling actually brought me to one of my first
> "a-ha!"
> >> moment in Rails (similar to when I first learned about the ++
operator
> in
> >> C). Finally, I thought, I don''t have to do anything to
set up the
> >> butt-simple relationships between models and tables that are found
(as
> you
> >> say) in 90% of web apps (and other applications, too). Rails
allows
> models
> >> as complicated as you want, and it also allows you to do work in
the
> >> database when you need to (I know "find_by_sql" is a
dirty word, but it
> >> allows me to perform pivots on multiple tables of millions of
rows,
> where AR
> >> simply could not handle the SQL). But it makes the overwhelmingly
common
> >> case simple, and I like that.
> >> So I''ve found that this model-db coupling to be a
powerful feature of
> Rails.
> >> I know it''s saved me a lot of work, because I''ve
had to do it manually
> so
> >> many other times in the last 25 years. If it''s not
sufficient or
> appropriate
> >> in any particular case, I don''t have to use it.
> >> I know this view puts me on the wrong side of the contest you
speak of
> >> (which I frankly didn''t even know I''d entered).
And yes, using Rails the
> way
> >> I (and many others) do involves trade-offs. But the one trade-off
it
> doesn''t
> >> require is with TSTTCPW, which is the guiding philosophy in
everything I
> do.
> >> I guess this makes me an AR pixie. :)
> >
> > I *think* Dan means underlying magic code when he uses the word pixie.
> >
>
> Dan always says pixies for stuff he doesn''t understand. They
don''t
> have pixies in England I think.
>
> Aslak
>
> >> ///ark
> >> _______________________________________________
> >> rspec-users mailing list
> >> rspec-users at rubyforge.org
> >> http://rubyforge.org/mailman/listinfo/rspec-users
> >>
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/rspec-users/attachments/20080930/badfed93/attachment.html>

I like them much better than the gremlins.

On 30 Sep 2008, at 14:09, Dan North wrote:
> We do have pixies! They do all the "magic" stuff.
>
> How else do you think it happens?
>
> ;)
>
>
> 2008/9/27 aslak hellesoy <aslak.hellesoy at gmail.com>
> On Sat, Sep 27, 2008 at 10:32 PM, David Chelimsky <dchelimsky at
gmail.com
> > wrote:
> > On Sat, Sep 27, 2008 at 2:29 PM, Mark Wilden <mark at
mwilden.com>
> wrote:
> >> On Sat, Sep 27, 2008 at 11:26 AM, Dan North <tastapod at
gmail.com>
> wrote:
> >>
> >>> It seems these conversations come up time and again because
Rails
> >>> overloads the idea of "model". In a Rails app the
model serves
> as both your
> >>> domain model and your persistence strategy, because of the  
> coupling inherent
> >>> in the Active Record pattern.
> >>
> >> Interesting. This coupling actually brought me to one of my first
> "a-ha!"
> >> moment in Rails (similar to when I first learned about the ++  
> operator in
> >> C). Finally, I thought, I don''t have to do anything to
set up the
> >> butt-simple relationships between models and tables that are  
> found (as you
> >> say) in 90% of web apps (and other applications, too). Rails  
> allows models
> >> as complicated as you want, and it also allows you to do work in  
> the
> >> database when you need to (I know "find_by_sql" is a
dirty word,
> but it
> >> allows me to perform pivots on multiple tables of millions of  
> rows, where AR
> >> simply could not handle the SQL). But it makes the overwhelmingly
> common
> >> case simple, and I like that.
> >> So I''ve found that this model-db coupling to be a
powerful
> feature of Rails.
> >> I know it''s saved me a lot of work, because I''ve
had to do it
> manually so
> >> many other times in the last 25 years. If it''s not
sufficient or
> appropriate
> >> in any particular case, I don''t have to use it.
> >> I know this view puts me on the wrong side of the contest you  
> speak of
> >> (which I frankly didn''t even know I''d entered).
And yes, using
> Rails the way
> >> I (and many others) do involves trade-offs. But the one trade-off
> it doesn''t
> >> require is with TSTTCPW, which is the guiding philosophy in  
> everything I do.
> >> I guess this makes me an AR pixie. :)
> >
> > I *think* Dan means underlying magic code when he uses the word  
> pixie.
> >
>
> Dan always says pixies for stuff he doesn''t understand. They
don''t
> have pixies in England I think.
>
> Aslak
>
> >> ///ark
> >> _______________________________________________
> >> rspec-users mailing list
> >> rspec-users at rubyforge.org
> >> http://rubyforge.org/mailman/listinfo/rspec-users
> >>
> > _______________________________________________
> > rspec-users mailing list
> > rspec-users at rubyforge.org
> > http://rubyforge.org/mailman/listinfo/rspec-users
> >
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

Fernando Perez wrote:
> Hi,
> 
> Today is a big day. I officially transitioned from manually testing by
> clicking around in my app, to automated testing with RSpec + Autotest.
6 months since my initial post, what happened in between?

- My controllers are getting anorexic, and that''s good. An action 
typically does only 1 call to a model and behind the scenes that model 
will make other calls to other models and do some fancy stuff, this used 
to happen in the controller which was bad. Now it has become so easy to 
write model specs.

- I don''t spec controllers, because it''s too painful to do. I
don''t spec
views either, because I tweak them too often, and it would take me more 
time rewriting view specs then actually coding the views. If there is 
something to test for is the rendering of the css across browsers, 
because that''s terrible!

- I use cucumber+webrat to test that some important public pages render 
without a 500 error. I don''t care if the view has such div except if it
is a critical one. What I mean is that I won''t test, all the
assignments
that should be on the page, as some tutorials demonstrate. This is 
nearly impossible to maintain.

- I can refactor my code, immediately spot areas where my code got 
broken, and fix it. Before some parts of my app would be broken without 
having me knowing about it for a long time until some cool customers 
report a few bugs, but this was not an acceptable situation.

- I don''t use Autotest, it sucks too much power, and it is too much 
distracting. From time to time I run specs to check if things look good, 
and always before updating the code on the server.

- I have written my own Factory. It''s not OOP, it could be refactored, 
but it works 100% as advertised, provides default values, can handle 
associations, etc. I am pleased with it (I tried factory girl, 
machinist, etc and got pissed off). I encourage anyone to write his own 
little factory, to get a better hang of how to write good specs. I 
totally got mad with fixtures, it is impossible to maintain specs/tests 
with fixtures. Impossible.

- I don''t do true BDD, i.e: I still write code before specs, because 
that''s what motivates me. I consider that seeing my app living and 
writing code for my app more important than writing specs. Specs are 
still important, but only as a bug reporting tool, they don''t add any 
value for the customer. In this crisis If I wanted an employee to resign 
by himself without paying him benefits (that''s how it works in Europe),
I would make him write specs all day long, and forbid him from seeing 
the app and play with it. He wouldn''t last 1 week doing this.

What about you?


Best regards,
-- 
Posted via http://www.ruby-forum.com/.

Fernando Perez wrote:
> 6 months since my initial post, what happened in between?
> 
> - My controllers are getting anorexic, and that''s good. An action 
> typically does only 1 call to a model and behind the scenes that model 
> will make other calls to other models and do some fancy stuff, this used 
> to happen in the controller which was bad. Now it has become so easy to 
> write model specs.
By "getting", do you mean new controllers arrive skinny? Or that you
have
refactored the same fat controllers, over time, until they are skinny?

The latter is preferred, because we should not be writing the same sites over 
and over again. In theory!
> - I don''t spec controllers, because it''s too painful to
do. I don''t spec
> views either, because I tweak them too often, and it would take me more 
> time rewriting view specs then actually coding the views. If there is 
> something to test for is the rendering of the css across browsers, 
> because that''s terrible!
We TDD, and refactor, the living shit out of controllers and views. Tools like 
assert_xhtml and form_test_helper make TDDing them easier than creating them by 
code-and-fix.
> - I use cucumber+webrat to test that some important public pages render 
> without a 500 error. I don''t care if the view has such div except
if it
> is a critical one. What I mean is that I won''t test, all the
assignments
> that should be on the page, as some tutorials demonstrate. This is 
> nearly impossible to maintain.
How often do you run your tests? Your editor should help you run them after 
every couple of edits. A lot of BDD is actually "cargo cult"
"Test-Driven
Development" (Google the terms independently to see what I mean).

Someone would get the benefits you describe doing just some of the TDD cycle, 
but if they left out other parts they might blame the views for the remaining 
irritations.
> - I can refactor my code, immediately spot areas where my code got 
> broken, and fix it. Before some parts of my app would be broken without 
> having me knowing about it for a long time until some cool customers 
> report a few bugs, but this was not an acceptable situation.
Right: Your car now has headlights, _and_ brakes. This means you can go faster.
> - I don''t use Autotest, it sucks too much power, and it is too
much
> distracting. From time to time I run specs to check if things look good, 
> and always before updating the code on the server.
But you should _want_ to test every few edits. More important, you should be 
able to correctly predict the result of each run.

-- 
   Phlip

> By "getting", do you mean new controllers arrive skinny? Or that
you
> have
> refactored the same fat controllers, over time, until they are skinny?
> 
> The latter is preferred, because we should not be writing the same sites 
> over
> and over again. In theory!
My good ole'' fat pig controllers, are now nice, slim and fancy :-)

> How often do you run your tests? Your editor should help you run them 
> after
> every couple of edits. A lot of BDD is actually "cargo cult" 
It depends. Overall I try to take small steps at a time. But never ever 
will I update the server code unless 100% specs pass!
> But you should _want_ to test every few edits. More important, you 
> should be
> able to correctly predict the result of each run.
As a habit I like to abuse of the save button even if I only corrected 
some typos in comments, or changed the indentation. Suddenly autotest 
would kick in for nothing.

Sometimes I save 4 files one after the other because I forgot about the 
keyboard short cut for saving them all at once, and autospec will run 4 
times instead of only once which is stupid. And growl will be notifying 
me each time which is very distracting.
-- 
Posted via http://www.ruby-forum.com/.

On Tue, Mar 31, 2009 at 5:39 AM, Fernando Perez <lists at ruby-forum.com>
wrote:
> Fernando Perez wrote:
>> Hi,
>>
>> Today is a big day. I officially transitioned from manually testing by
>> clicking around in my app, to automated testing with RSpec + Autotest.
>
> 6 months since my initial post, what happened in between?
>
> - My controllers are getting anorexic, and that''s good. An action
> typically does only 1 call to a model and behind the scenes that model
> will make other calls to other models and do some fancy stuff, this used
> to happen in the controller which was bad. Now it has become so easy to
> write model specs.
Great! Keeping controllers simple makes life better on many fronts.
>
> - I don''t spec controllers, because it''s too painful to
do. I don''t spec
> views either, because I tweak them too often, and it would take me more
> time rewriting view specs then actually coding the views. If there is
> something to test for is the rendering of the css across browsers,
> because that''s terrible!
I usually let Cucumber run through the basics of the action, but I
write controller specs for interesting thing that affect the behaviour
of an action such as requiring logic, or a certain permission, or
special error handling logic, etc. Pulling these things out into a
controller macro makes re-using them extremely simple. The next beta
release for The RSpec Book will cover doing that.

I write view specs because they *change* so much. I don''t spec the
structure of the page, just the semantics of it as it pertains to
information I programmatically display or don''t display. IME, when
apps are small there is a feeling that Cucumber can do it all, but as
the app grows Cucumber can be a burden as well. Cucumber scenarios
can''t do it all, and when you have interesting apps, hundreds of
scenarios and hundreds of steps it becomes way too time consuming to
try to find exactly what and why things died and why. I prefer focused
view specs for this regression rather than simply relying on Cucumber.
 Also cucumber step definitions can become large and unwieldy. I like
focused steps which do enough to prove a scenario works as expected
and I like to drop down to specs for the details of it.
>
> - I use cucumber+webrat to test that some important public pages render
> without a 500 error. I don''t care if the view has such div except
if it
> is a critical one. What I mean is that I won''t test, all the
assignments
> that should be on the page, as some tutorials demonstrate. This is
> nearly impossible to maintain.
I disagree with the last two sentences here. I build my views spec
first with examples that expect the result of "project.name" to be on
the page. Only then do I actually add it to the view. I have had no
issue maintaining this. Not only do I get a design benefit when its
not just a simple model attribute, but perhaps a calculated field, I
also get regression for free. I move swiftly, happily, and confidently
on without worrying about manually verifying everything on the page is
as it should be, I let my specs do that.
>
> - I can refactor my code, immediately spot areas where my code got
> broken, and fix it. Before some parts of my app would be broken without
> having me knowing about it for a long time until some cool customers
> report a few bugs, but this was not an acceptable situation.
IMO, this is the case when people don''t write view specs. Unless
someone''s Cucumber scenario covers everything on the view (which they
don''t unless its a super simple CRUD app). Half the time I wonder if
people even know if their views are displaying the write things on the
page over time. How would they not know w/o specs? Do they manually
verify every page every time they deploy? That seems impossible to
maintain.
>
> - I don''t use Autotest, it sucks too much power, and it is too
much
> distracting. From time to time I run specs to check if things look good,
> and always before updating the code on the server.
Agreed. I loathe autotest, but I don''t run specs time to time, I run
my specs all the time. It''s a part of my development process. Red
Green Refactor. It''s not just a mantra, its a discipline. Although
when I don''t know what I want or need to do, I spike something
(without any tests), and once I figure it out I scrape the spike (or
comment it out) and drive it with examples.
>
> - I have written my own Factory. It''s not OOP, it could be
refactored,
> but it works 100% as advertised, provides default values, can handle
> associations, etc. I am pleased with it (I tried factory girl,
> machinist, etc and got pissed off). I encourage anyone to write his own
> little factory, to get a better hang of how to write good specs. I
> totally got mad with fixtures, it is impossible to maintain specs/tests
> with fixtures. Impossible.
Cool. Is it on github? I wrote my own as well, but then switched to
FactoryGirl because everyone I talked to loved it, but now I wonder if
they really loved it (or how much they actually use it) because it
works for about 80% of the things I need, and fails horribly for the
other 20%. I want to try Machinist next, but I''m sad to see you had
bad experiences with it. :(

And I hate the idea behind ObjectDaddy, adding methods to the model to
generate spec data. Gross.
> - I don''t do true BDD, i.e: I still write code before specs,
because
> that''s what motivates me. I consider that seeing my app living and
> writing code for my app more important than writing specs. Specs are
> still important, but only as a bug reporting tool, they don''t add
any
> value for the customer. In this crisis If I wanted an employee to resign
> by himself without paying him benefits (that''s how it works in
Europe),
> I would make him write specs all day long, and forbid him from seeing
> the app and play with it. He wouldn''t last 1 week doing this.
>
> What about you?
>
You''ve probably seen this, but it never gets old, "Testing is for
testers." When you focus on specs solely for the benefit of testing
then you are only getting the tip of the ice berg. Traditional "tests"
are really they to provide safeguard against regression. This is a
secondary benefit to BDD. BDD is about driving your app from the
outside in, focusing on the behaviour at different levels.

For example, Cucumber lets you focus on the app behaviour, while view
specs lets you focus on the expected behaviour of a view (to display
"project.name"), and controller specs let you focus on the behaviour
of a controller (such that only "admins" can destroy a project), and
model specs let you provide examples for how it should be working.
Focusing on the behaviour at these different levels forces you to
write better designed code, more focused objects, simpler controllers,
just-the-right size models, etc.

A better design lets you move fluidly through the app as it evolves
and changes. When you use BDD, you get a better design as a part of
the process. As a nice secondary benefit you get protection against
unwanted regression.

I encourage you and anyone else to practice your BDD more. The more I
practice the more fluently I can drive my app with examples form the
outside-in, and the more capable I am to know when to write a
controller spec and when not to---and it''s not based on if it takes
too long. The decision is based on experience for knowing how-to do
it, and how-to do it well, and then asking myself, "Does this get me
anything?"

Not spe''cing something because you don''t know how-to spec it
well is
most likely not an issue with BDD. It''s a skill deficiency with the
developer. The only way to make good decisions it practice and become
more familiar with your tools. Then you will start making informed
decisions that add value to your project. The alternative is that you
make uninformed decisions and you or other developers will suffer down
the road because you made a bad decision but didn''t know it because
you lacked the knowledge and/or experience to know it was a bad
decision.

>
> Best regards,
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>


-- 
Zach Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com

Fernando Perez wrote:
> As a habit I like to abuse of the save button even if I only corrected 
> some typos in comments, or changed the indentation. Suddenly autotest 
> would kick in for nothing.
Autotest sucks. If we have too many tests, it runs them all, and this slows us
down.

Our editor support for TDD also sucks. It should run the most recently edited 
test cases, nearly automatically. Everyone swears by Textmate, and it simply 
can''t do that. Then, the Java-based editors also can''t do it!

On Tue, Mar 31, 2009 at 12:16 PM, Phlip <phlip2005 at gmail.com>
wrote:
> Fernando Perez wrote:
>
>> As a habit I like to abuse of the save button even if I only corrected
>> some typos in comments, or changed the indentation. Suddenly autotest
would
>> kick in for nothing.
>
> Autotest sucks. If we have too many tests, it runs them all, and this slows
> us down.
Or, conversely, autotest is awesome if you take the time to learn how to use it:

http://blog.davidchelimsky.net/2008/3/5/limiting-scope-of-autotest
>
> Our editor support for TDD also sucks. It should run the most recently
> edited test cases, nearly automatically. Everyone swears by Textmate, and
it
> simply can''t do that. Then, the Java-based editors also
can''t do it!
>
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On Tue, Mar 31, 2009 at 1:10 PM, Zach Dennis <zach.dennis at gmail.com>
wrote:
> On Tue, Mar 31, 2009 at 5:39 AM, Fernando Perez <lists at
ruby-forum.com> wrote:
>> Fernando Perez wrote:
>>> Hi,
>>>
>>> Today is a big day. I officially transitioned from manually testing
by
>>> clicking around in my app, to automated testing with RSpec +
Autotest.
>>
>> 6 months since my initial post, what happened in between?
>>
>> - My controllers are getting anorexic, and that''s good. An
action
>> typically does only 1 call to a model and behind the scenes that model
>> will make other calls to other models and do some fancy stuff, this
used
>> to happen in the controller which was bad. Now it has become so easy to
>> write model specs.
>
> Great! Keeping controllers simple makes life better on many fronts.
>
>>
>> - I don''t spec controllers, because it''s too painful
to do. I don''t spec
>> views either, because I tweak them too often, and it would take me more
>> time rewriting view specs then actually coding the views. If there is
>> something to test for is the rendering of the css across browsers,
>> because that''s terrible!
>
> I usually let Cucumber run through the basics of the action, but I
> write controller specs for interesting thing that affect the behaviour
> of an action such as requiring logic, or a certain permission, or
> special error handling logic, etc. Pulling these things out into a
> controller macro makes re-using them extremely simple. The next beta
> release for The RSpec Book will cover doing that.
>
> I write view specs because they *change* so much. I don''t spec the
> structure of the page, just the semantics of it as it pertains to
> information I programmatically display or don''t display. IME, when
> apps are small there is a feeling that Cucumber can do it all, but as
> the app grows Cucumber can be a burden as well. Cucumber scenarios
> can''t do it all, and when you have interesting apps, hundreds of
> scenarios and hundreds of steps it becomes way too time consuming to
> try to find exactly what and why things died and why. I prefer focused
> view specs for this regression rather than simply relying on Cucumber.
> ?Also cucumber step definitions can become large and unwieldy. I like
> focused steps which do enough to prove a scenario works as expected
> and I like to drop down to specs for the details of it.
>
>>
>> - I use cucumber+webrat to test that some important public pages render
>> without a 500 error. I don''t care if the view has such div
except if it
>> is a critical one. What I mean is that I won''t test, all the
assignments
>> that should be on the page, as some tutorials demonstrate. This is
>> nearly impossible to maintain.
>
> I disagree with the last two sentences here. I build my views spec
> first with examples that expect the result of "project.name" to
be on
> the page. Only then do I actually add it to the view. I have had no
> issue maintaining this. Not only do I get a design benefit when its
> not just a simple model attribute, but perhaps a calculated field, I
> also get regression for free. I move swiftly, happily, and confidently
> on without worrying about manually verifying everything on the page is
> as it should be, I let my specs do that.
>
>>
>> - I can refactor my code, immediately spot areas where my code got
>> broken, and fix it. Before some parts of my app would be broken without
>> having me knowing about it for a long time until some cool customers
>> report a few bugs, but this was not an acceptable situation.
>
> IMO, this is the case when people don''t write view specs. Unless
> someone''s Cucumber scenario covers everything on the view (which
they
> don''t unless its a super simple CRUD app). Half the time I wonder
if
> people even know if their views are displaying the write things on the
> page over time. How would they not know w/o specs? Do they manually
> verify every page every time they deploy? That seems impossible to
> maintain.
>
>>
>> - I don''t use Autotest, it sucks too much power, and it is too
much
>> distracting. From time to time I run specs to check if things look
good,
>> and always before updating the code on the server.
>
> Agreed. I loathe autotest, but I don''t run specs time to time, I
run
> my specs all the time. It''s a part of my development process. Red
> Green Refactor. It''s not just a mantra, its a discipline. Although
> when I don''t know what I want or need to do, I spike something
> (without any tests), and once I figure it out I scrape the spike (or
> comment it out) and drive it with examples.
>
>>
>> - I have written my own Factory. It''s not OOP, it could be
refactored,
>> but it works 100% as advertised, provides default values, can handle
>> associations, etc. I am pleased with it (I tried factory girl,
>> machinist, etc and got pissed off). I encourage anyone to write his own
>> little factory, to get a better hang of how to write good specs. I
>> totally got mad with fixtures, it is impossible to maintain specs/tests
>> with fixtures. Impossible.
>
> Cool. Is it on github? I wrote my own as well, but then switched to
> FactoryGirl because everyone I talked to loved it, but now I wonder if
> they really loved it (or how much they actually use it) because it
> works for about 80% of the things I need, and fails horribly for the
> other 20%. I want to try Machinist next, but I''m sad to see you
had
> bad experiences with it. :(
>
> And I hate the idea behind ObjectDaddy, adding methods to the model to
> generate spec data. Gross.
>
>> - I don''t do true BDD, i.e: I still write code before specs,
because
>> that''s what motivates me. I consider that seeing my app living
and
>> writing code for my app more important than writing specs. Specs are
>> still important, but only as a bug reporting tool, they don''t
add any
>> value for the customer. In this crisis If I wanted an employee to
resign
>> by himself without paying him benefits (that''s how it works in
Europe),
>> I would make him write specs all day long, and forbid him from seeing
>> the app and play with it. He wouldn''t last 1 week doing this.
>>
>> What about you?
>>
>
> You''ve probably seen this, but it never gets old, "Testing is
for
> testers." When you focus on specs solely for the benefit of testing
> then you are only getting the tip of the ice berg. Traditional
"tests"
> are really they to provide safeguard against regression. This is a
> secondary benefit to BDD. BDD is about driving your app from the
> outside in, focusing on the behaviour at different levels.
>
> For example, Cucumber lets you focus on the app behaviour, while view
> specs lets you focus on the expected behaviour of a view (to display
> "project.name"), and controller specs let you focus on the
behaviour
> of a controller (such that only "admins" can destroy a project),
and
> model specs let you provide examples for how it should be working.
> Focusing on the behaviour at these different levels forces you to
> write better designed code, more focused objects, simpler controllers,
> just-the-right size models, etc.
>
> A better design lets you move fluidly through the app as it evolves
> and changes. When you use BDD, you get a better design as a part of
> the process. As a nice secondary benefit you get protection against
> unwanted regression.
>
> I encourage you and anyone else to practice your BDD more. The more I
> practice the more fluently I can drive my app with examples form the
> outside-in, and the more capable I am to know when to write a
> controller spec and when not to---and it''s not based on if it
takes
> too long. The decision is based on experience for knowing how-to do
> it, and how-to do it well, and then asking myself, "Does this get me
> anything?"
>
> Not spe''cing something because you don''t know how-to spec
it well is
> most likely not an issue with BDD. It''s a skill deficiency with
the
> developer. The only way to make good decisions it practice and become
> more familiar with your tools. Then you will start making informed
> decisions that add value to your project. The alternative is that you
> make uninformed decisions and you or other developers will suffer down
> the road because you made a bad decision but didn''t know it
because
> you lacked the knowledge and/or experience to know it was a bad
> decision.
This isn''t intended at you Fernando. This is just "in
general" my
thoughts, all of which have come from my own journey, as well as many
discussions on-line and off-line.

>
>
>>
>> Best regards,
>> --
>> Posted via http://www.ruby-forum.com/.
>> _______________________________________________
>> rspec-users mailing list
>> rspec-users at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/rspec-users
>>
>
>
>
> --
> Zach Dennis
> http://www.continuousthinking.com
> http://www.mutuallyhuman.com
>


-- 
Zach Dennis
http://www.continuousthinking.com
http://www.mutuallyhuman.com

Hi Phlip,
On 31/03/2009, Phlip <phlip2005 at gmail.com> wrote:
>  Our editor support for TDD also sucks. It should run the most recently
> edited test cases, nearly automatically. Everyone swears by Textmate, and
it
> simply can''t do that. Then, the Java-based editors also
can''t do it!
What editor are you then proposing? Or are you saying that all current
editors lag behind XP practices?

Aidy

On Tue, Mar 31, 2009 at 4:39 AM, Fernando Perez <lists at ruby-forum.com>
wrote:
> Fernando Perez wrote:
>> Hi,
>>
>> Today is a big day. I officially transitioned from manually testing by
>> clicking around in my app, to automated testing with RSpec + Autotest.
>
> 6 months since my initial post, what happened in between?
>
> - My controllers are getting anorexic, and that''s good. An action
> typically does only 1 call to a model and behind the scenes that model
> will make other calls to other models and do some fancy stuff, this used
> to happen in the controller which was bad. Now it has become so easy to
> write model specs.
>
> - I don''t spec controllers, because it''s too painful to
do. I don''t spec
> views either, because I tweak them too often, and it would take me more
> time rewriting view specs then actually coding the views. If there is
> something to test for is the rendering of the css across browsers,
> because that''s terrible!
>
> - I use cucumber+webrat to test that some important public pages render
> without a 500 error. I don''t care if the view has such div except
if it
> is a critical one. What I mean is that I won''t test, all the
assignments
> that should be on the page, as some tutorials demonstrate. This is
> nearly impossible to maintain.
>
> - I can refactor my code, immediately spot areas where my code got
> broken, and fix it. Before some parts of my app would be broken without
> having me knowing about it for a long time until some cool customers
> report a few bugs, but this was not an acceptable situation.
>
> - I don''t use Autotest, it sucks too much power, and it is too
much
> distracting. From time to time I run specs to check if things look good,
> and always before updating the code on the server.
>
> - I have written my own Factory. It''s not OOP, it could be
refactored,
> but it works 100% as advertised, provides default values, can handle
> associations, etc. I am pleased with it (I tried factory girl,
> machinist, etc and got pissed off). I encourage anyone to write his own
> little factory, to get a better hang of how to write good specs. I
> totally got mad with fixtures, it is impossible to maintain specs/tests
> with fixtures. Impossible.
>
> - I don''t do true BDD, i.e: I still write code before specs,
because
> that''s what motivates me. I consider that seeing my app living and
> writing code for my app more important than writing specs. Specs are
> still important, but only as a bug reporting tool, they don''t add
any
> value for the customer.
Please be careful when making absolute statements like this. First of
all, even "just a bug reporting tool" adds tremendous value for the
customer, because your catching bugs before they make it to
production.

Secondly, the value to your customer of writing specs before code
depends on your personal skill level as it relates to writing them.
Spec-first adds considerable value for my customers because I know how
to move quickly through the red/green/refactor cycle, and it does
impact design, and therefore the quality of my code, and therefore the
short and long term maintenance costs. But, admittedly, I''ve been on
the TDD train ever since I learned about it back in 2003 and I kinda
know what I''m doing.
> In this crisis If I wanted an employee to resign
> by himself without paying him benefits (that''s how it works in
Europe),
> I would make him write specs all day long, and forbid him from seeing
> the app and play with it. He wouldn''t last 1 week doing this.
Nor would anybody. From what you''re writing, it sounds like your
perception is that you write a bunch of specs with no code, and then
write code to pass the specs.

The point of TDD is writing small examples and small bits of code in a
cycle. The point of BDD is to write high level scenarios so you know
what code to write, but then drive it out in detail with TDD. My
personal experience is that writing this way is a lot of fun, filled
with small successes every few minutes. Admittedly, it''s not always as
fun as hacking together a quick prototype and seeing it come to life.
But the fun of that approach dies very quickly if the prototype
becomes the actual app and I find myself back-filling specs.

Hope that helps clarify.

Cheers,
David
> What about you?
>
>
> Best regards,
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

> Or, conversely, autotest is awesome if you take the time to learn how to 
> use it:
> 
> http://blog.davidchelimsky.net/2008/3/5/limiting-scope-of-autotest
Well, I find it easier to simply type:

$ rake spec

Then depending on what failed I will from time to time run a single spec 
file:

$ spec spec/models/whatever.rb

-- 
Posted via http://www.ruby-forum.com/.

aidy lewis wrote:
> What editor are you then proposing? Or are you saying that all current
> editors lag behind XP practices?
http://www.oreillynet.com/onlamp/blog/2008/05/dynamic_languages_vs_editors.html

> Please be careful when making absolute statements like this. First of
> all, even "just a bug reporting tool" adds tremendous value for
the
> customer, because your catching bugs before they make it to
> production.
Value is what a customer is something he is ready to pay more money for. 
Well, we could argue that specing/testing  can improve my workflow and 
get new features added or improved faster... A Ferrari could also get me 
to work quicker ;-)
-- 
Posted via http://www.ruby-forum.com/.

David Chelimsky wrote:
> Or, conversely, autotest is awesome if you take the time to learn how to
use it:
> 
> http://blog.davidchelimsky.net/2008/3/5/limiting-scope-of-autotest
Even with -f, after it ran our most recently changed test...

...it started the grand wazoo test batch.

Pass! I can just use autotask or the truly stupid trigger.rb script I drag 
around to TDD. They would just defer to test:recent. We have our suites and 
files all cut up into bite-sized chunks for a reason...

On Tue, Mar 31, 2009 at 2:19 PM, Fernando Perez <lists at ruby-forum.com>
wrote:
>> Please be careful when making absolute statements like this. First of
>> all, even "just a bug reporting tool" adds tremendous value
for the
>> customer, because your catching bugs before they make it to
>> production.
> Value is what a customer is something he is ready to pay more money for.
> Well, we could argue that specing/testing ?can improve my workflow and
> get new features added or improved faster... A Ferrari could also get me
> to work quicker ;-)
If (if!!!!) writing specs first makes you go faster, then you''re
faster for free. The Ferrari bears a bit of a different cost/benefit
ratio :)

Cheers,
David
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

On 31 Mar 2009, at 18:19, David Chelimsky wrote:
>> Autotest sucks. If we have too many tests, it runs them all, and  
>> this slows
>> us down.
>
> Or, conversely, autotest is awesome if you take the time to learn  
> how to use it:
>
> http://blog.davidchelimsky.net/2008/3/5/limiting-scope-of-autotest

Thank you.

Matt Wynne
http://blog.mattwynne.net
http://www.songkick.com

Hi David

2009/3/31 David Chelimsky <dchelimsky at gmail.com>:
> The point of TDD is writing small examples and small bits of code in a
> cycle. The point of BDD is to write high level scenarios so you know
> what code to write, but then drive it out in detail with TDD.
Does this necessitate that the same person or pair should be doing
both the TDD and BDD for the same area? My problem at the moment is
that as a software tester I would in combination with a customer
create the feature Acceptance Criteria (AC). The AC would be used by
the developer to guide his\her design, but he\she would be unlikely to
implement the automated test, which would normally be done by the
tester (using Watir\Cucumber). My feeling is that if we are to get the
optimal benefit from TDD\BDD then the developer(s) should be
automating the AC. What do you think?

I don''t think this removes the need of the tester as he/she may be
more likely to have a skill-set that is aware of
bigger-than-unit-test-tools and frameworks, but I think they should be
pairing with the developer. However the problem then arises if the
developer and tester use different languages. I use Ruby while the
production code is in .Net. The TDD interplay would be more seamless I
think with a single language. But as a tester it would be insane for
me to use a static and compiled language to - in effect - test a web
site.

Aidy

On Wed, Apr 1, 2009 at 8:01 AM, aidy lewis <aidy.lewis at googlemail.com>
wrote:
> Hi David
>
> 2009/3/31 David Chelimsky <dchelimsky at gmail.com>:
>
>> The point of TDD is writing small examples and small bits of code in a
>> cycle. The point of BDD is to write high level scenarios so you know
>> what code to write, but then drive it out in detail with TDD.
>
> Does this necessitate that the same person or pair should be doing
> both the TDD and BDD for the same area? My problem at the moment is
> that as a software tester I would in combination with a customer
> create the feature Acceptance Criteria (AC). The AC would be used by
> the developer to guide his\her design, but he\she would be unlikely to
> implement the automated test, which would normally be done by the
> tester (using Watir\Cucumber). My feeling is that if we are to get the
> optimal benefit from TDD\BDD then the developer(s) should be
> automating the AC. What do you think?
Given that I don''t know the skill-set available on your team,
it''s
difficult for me to say what would provide optimum benefit for *your
team*. That said, in some idealistic BDD fashion, I''d think the best
deal would be the tester and developer pairing on automating AC. Then
that developer would pair with another developer driving out the code
w/ TDD.
> I don''t think this removes the need of the tester as he/she may be
> more likely to have a skill-set that is aware of
> bigger-than-unit-test-tools and frameworks, but I think they should be
> pairing with the developer.
I honestly wrote the above before I read this :) Yes, I agree, tester
and developer pairing is *generally* a good thing.
> However the problem then arises if the
> developer and tester use different languages. I use Ruby while the
> production code is in .Net. The TDD interplay would be more seamless I
> think with a single language. But as a tester it would be insane for
> me to use a static and compiled language to - in effect - test a web
> site.
I''m going to go out on a limb here and suggest that if you''re
proficient in Ruby and you''re pairing with a reasonably skilled
developer in any C-based language like C Sharp, the language barrier
will be fairly small. There are some hoops, like meta-programming,
blocks and iterators, but not too many beyond that. I don''t mean that
to be flippant. Even if the dev has zero experience with these
concepts, he really doesn''t need to understand them in order to
progress if you''re pairing.

HTH,
David
>
> Aidy
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
>

Hi David

2009/4/1 David Chelimsky <dchelimsky at gmail.com>:
>. That said, in some idealistic BDD fashion, I''d think the best
> deal would be the tester and developer pairing on automating AC. Then
> that developer would pair with another developer driving out the code
> w/ TDD.
If we have two different sets of people implementing the AC and
driving code with TDD then does this not prevent the TDD\BDD
interplay? Development is in small steps, so if we create a mock for
the first AC step see it fail then move down into TDD to make that
pass, refactor then move up (red => green => refactor) again - then
this - to me -, has surely got to be done by the same set off people.
I think the user step mocks are likely to be re-factored out when we
have some tangible output (e.g a GUI)
> I''m going to go out on a limb here and suggest that if
you''re
> proficient in Ruby and you''re pairing with a reasonably skilled
> developer in any C-based language like C Sharp, the language barrier
> will be fairly small. There are some hoops, like meta-programming,
> blocks and iterators, but not too many beyond that. I don''t mean
that
> to be flippant. Even if the dev has zero experience with these
> concepts, he really doesn''t need to understand them in order to
> progress if you''re pairing.
>
When you go to Harversters they ask ''have you been here
before?''.
Maybe not, but I can eat with a knife and fork.

However, - I will put myself on a limb - some programmers have been
conditioned by MS on the practices and uses of tools. No intellisense,
no visual debugger, no static assignment or compilation, a command
line!*@? Many are just not happy with it.

Aidy

> 6 months since my initial post, what happened in between?
Damn! BDD + writing specs that don''t hit the database, also taught me
to
not break Demeter''s law :-D

It''s simply a huge pain to spec a double dot method call, i.e: 
user.membership.paid?

ActiveRecord associations are super, but they can back fire pretty bad 
if you abuse them.
-- 
Posted via http://www.ruby-forum.com/.