Rails - Nov 2006 - TDD killing my joy of Rails

I''ve been working through the book ''Beginning Ruby on Rails
E-Commerce''
which is very heavy on Test Driven Development.  As in, you have to
write tests for scaffolding methods and validations and crap like that.
And then they fail.  And you KNOW its the test not the method.  So you
spend 2x the time writing a test that has to be adapted when
requirements change.  You really are doubling / tripling your code.

Rails went from fun ActiveRecord magic tricks to a world of ''TEST
FAILED.''  As a beginning Rails developer it has really taken all the
fun
out of RoR development.  Is TDD so much better than writing methods and
testing using a combination of the application interface and Navicat to
check the database?  Because I hate it.

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

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On 11/30/06, Taylor Strait
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
>
> I''ve been working through the book ''Beginning Ruby on
Rails E-Commerce''
> which is very heavy on Test Driven Development.  As in, you have to
> write tests for scaffolding methods and validations and crap like that.
> And then they fail.  And you KNOW its the test not the method.  So you
> spend 2x the time writing a test that has to be adapted when
> requirements change.  You really are doubling / tripling your code.
>
> Rails went from fun ActiveRecord magic tricks to a world of ''TEST
> FAILED.''  As a beginning Rails developer it has really taken all
the fun
> out of RoR development.  Is TDD so much better than writing methods and
> testing using a combination of the application interface and Navicat to
> check the database?  Because I hate it.
It is a lot of extra work.  The # of lines of code usually outnumber
my actual app.  But, it''s better than having a team of monkeys
clicking on every single link in my app everytime I deploy.

-- 
Rick Olson
http://weblog.techno-weenie.net
http://mephistoblog.com

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Nov 30, 2006, at 3:31 PM, Taylor Strait wrote:
> Rails went from fun ActiveRecord magic tricks to a world of ''TEST
> FAILED.''  As a beginning Rails developer it has really taken all  
> the fun
> out of RoR development.
Well, TDD *is* a choice. If it''s bad for you, exercise free will!
> Is TDD so much better than writing methods and
> testing using a combination of the application interface and  
> Navicat to
> check the database?
Yes, it is. No question in my mind. TDD generally will slow you down
when you start using it, like anything new. But you''ll soon get into
the habbit, and you''ll be writing better code.

The big boost the you cannot see since you haven''t experienced it yet,
is when the application becomes more complex, and you make a change that
you KNOW works fine, and a test fails. You''ll grumble and say,
"You see,
THAT is why I hate TDD."

Then, while fixing the damn test, you''ll realize there''s
nothing wrong
with it. You''ll then know, without question, why TDD works. It allows
you to make not only trivial changes with confidence, but serious tear
the wires out changes, and know that when the tests pass, you''re good
to go.
> Because I hate it.
That''s a not insignificant part of the problem. :-)

-- 
-- Tom Mornini, CTO
-- Engine Yard, Ruby on Rails Hosting
-- Reliability, Ease of Use, Scalability
-- (866) 518-YARD (9273)


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Taylor Strait wrote:
> I''ve been working through the book ''Beginning Ruby on
Rails E-Commerce''
> which is very heavy on Test Driven Development.  As in, you have to
> write tests for scaffolding methods and validations and crap like that.
> And then they fail.  And you KNOW its the test not the method.  So you
> spend 2x the time writing a test that has to be adapted when
> requirements change.  You really are doubling / tripling your code.
>
> Rails went from fun ActiveRecord magic tricks to a world of ''TEST
> FAILED.''  As a beginning Rails developer it has really taken all
the fun
> out of RoR development.  Is TDD so much better than writing methods and
> testing using a combination of the application interface and Navicat to
> check the database?  Because I hate it.
Rails makes test-first somewhat hard, but still much easier than Brand X. 
You are lucky to have a book that gets you over the curve - and you just 
recommended an otherwise boring title to me!

The fall-back is "developer-centric testing" where you alternate
writing
test cases, writing code, and editing the test cases so they accept the code 
you wrote. I suspect that''s how Rails itself was invented, and
it''s a big
part of the reason why Rails is so powerful.

Tests break when you make big changes. The fix is to not make big changes. 
Make very small changes and pass all tests. When requirements change, 
introduce the new requirement one tiny feature at a time. If a test fails, 
inspect it to see if it prevented you from making a mistake; if not, adjust 
it to the new requirements.

With even a little automated testing, you will debug much less, and your 
projects have much more momentum. You can make small edits and run tests 
with general assurance that things you forgot about did not break.

Without that support, you get debugging and churn, where fixing bugs causes 
more bugs. Yes, some of us feel nostalgia for the olden days, when the Quest 
for Bugs made us feel heroic. Get over it.

Under Debugger Driven Development, you start with fun magic tricks, and 
descend into a nightmare of "app failed!". And you might not even have
a
clue which module to inspect.

Under TDD, if your program unexpectedly fails, you have an option that 
debugging can''t provide:

 -> you can revert your change <-

Treat that like a magic button on your editor called "kill bug". 
Debugger-driven development simply doesn''t provide that simple option.

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!!


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Taylor,

I hear ya... Writing tests can be a major pain in the butt. I don''t
know if
it''s possible to truly enjoy it, but it can really make a big
difference in
the long run. You can actually think of it as just another type of
Don''t
Repeat Yourself, in that you''re putting in some extra work at the front
end
in order to save yourself from having to test and re-test stuff manually as
your app grows and evolves.

If you write your tests well (and this is probably the hardest part, IMHO),
they can immediately alert you to problems you create as you go along, and
bugs that get introduced as you change functionality. My worst enemy are
always the unintended side effects of a modification... With well written
tests, there is much less chance that this will be a problem.

And as I''m spending my day today writing a bunch of tests, I''m
preaching to
myself a bit too ;)

Good luck,

Matt

On 12/1/06, Taylor Strait
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
>
>
> I''ve been working through the book ''Beginning Ruby on
Rails E-Commerce''
> which is very heavy on Test Driven Development.  As in, you have to
> write tests for scaffolding methods and validations and crap like that.
> And then they fail.  And you KNOW its the test not the method.  So you
> spend 2x the time writing a test that has to be adapted when
> requirements change.  You really are doubling / tripling your code.
>
> Rails went from fun ActiveRecord magic tricks to a world of ''TEST
> FAILED.''  As a beginning Rails developer it has really taken all
the fun
> out of RoR development.  Is TDD so much better than writing methods and
> testing using a combination of the application interface and Navicat to
> check the database?  Because I hate it.
>
> --
> Posted via http://www.ruby-forum.com/.
>
> >
>

-- 
Matt White
-----------------------
Thermal Creative
http://blog.thermalcreative.com


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Taylor Strait wrote:
> Rails went from fun ActiveRecord magic tricks to a world of ''TEST
> FAILED.''
This guy named DHH seems to agree with you:

http://www.43things.com/people/progress/David/16399

"I''ve been a test-driven developer for quite a while, but I
haven''t
really gotten into the religious test-first branch yet."

Who does he think he is??

-- 
  Phlip
  http://c2.com/cgi/wiki?ZeekLand  <-- NOT a blog!!

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Nov 30, 2006, at 6:31 PM, Taylor Strait wrote:
> Rails went from fun ActiveRecord magic tricks to a world of ''TEST
> FAILED.''
some people take the approach of stubbing all the tests you can think  
of before you write the code (def test_should_incinerate_pie; end),  
making sure the code more or less works, then running the existing  
test suite to verify that you haven''t broken anyway, and last,  
actually writing the contents of all those tests you stubbed out.  it  
isn''t as pure as tdd, but it does accomplish some of the major goals  
(think about what should work and how, and be able to validate that  
you have no regressions).

-faisal


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

> On Nov 30, 2006, at 6:31 PM, Taylor Strait wrote:
>> Rails went from fun ActiveRecord magic tricks to a world of
''TEST
>> FAILED.''
> 
I''m a newbie to TDD, and ran into it slightly BEFORE I hooked up with 
Rails.  In my "real job", automated testing requirements came in
without
the rest of the Agile approach in place, and there, it has been a real 
drag to get into TDD.  I was lucky to have a member of my team who was 
not new to it, and he started feeding me the zen of TDD in the right 
way.  Not "we will now write tests for everything in the world before we 
write the application".

The job before us involved creating both a new XML based GUI layer and 
also the glue and support code needed to hook that to an existing set of 
"middleware" (this is phone UI stuff).  I was doing the glue/support 
code, and he was in charge of writing the XML stuff.  He helped me 
realize that the easy way for him to communicate just what he needed 
from my part, was to write a test.  He would send me an email something 
to the effect of "I just added a test for BLAH", and then I would go
off
and write some stuff that makes his test pass, then he would hook that 
up to his XML and goodness would happen.

Every now and then he would add to or change a test and say "I just 
realized I also needed fooBah, so I just broke the test", and I would go 
in and instantly see from his test exactly what I needed to add to my 
code.  It has been a delightful way to communicate specific requirements 
for our interface.

The key here is that we didn''t write "all the tests" and then
write "all
the code".  Instead, we developed the app one piece at a time and used 
the tests as a way to communicate what the top layer needed from the 
lower layer.

Now we are into the last phase of the project where we are doing 
profiling and looking for things to optimize.  Taking specific large 
hunks of my code and rewriting it is not a scary thing, even with the 
release just days away, because I can and do run all of the tests after 
I make both big and small changes, and when all the tests pass, 
everything just works.  Magic.

So I would say that you need to look at TDD in Rails more in line with 
the Agile way of developing an app, quite like the process that the 
"Dave''s" lay out in the Agile Rails book.  The stuff about
showing the
client and the client says "wow, that''s great, but what about
yadda
yadda", and that takes us to the next part of the development.  Instead 
of designing the whole thing down to the last iota of specificity before 
you start, you just kind of feel your way through it, and you do the 
tests as you go.  Any you and the "business people" play with it a bit
and you notice something and you say, "hey, I shouldn''t be able to
enter
so and so in this field" - translation "write a test that fails if the
user can successfully enter so and so in the field", run it to verify 
that it is breaking, then add the code that makes it pass.

It isn''t about spending 40 days and 40 nights writing tests before you 
start on the real app.  It''s just a different way of designing and 
developing a product, that includes creating a "proof of the pudding"
as
you go.  Five minutes thinking about the state of the app and how to 
take it to the next (tiny) level, followed by five minutes of writing a 
few tests and five minutes of making the tests pass, and viola, we''ve 
achieved a new level with our app, and we know it works right.

And because of the TDD approach, every little hunk of the project works 
perfectly (within the limits of the requirements we have defined -- i.e. 
the tests we have written) as we go, so there just isn''t any of the old
way of "OK, it''s feature complete -- in a few months we should
have some
of it actually working right".


jp

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

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Despite all of the stuff you hear about how it will save you time in the
future, you''ll know when it breaks, etc, there is one huge benefit that
you
will soon realize that, to me, outweighs the rest:

It forces you to think about your logic twice.  Once when you write your
tests, and once again when you write your code.

Unit tests let you get your business rules into code really quickly. If you
do all of your business logic in the models, then this is more apparent.
For example... you may create a new user, but doing so will mean that he
will need to be assigned a default role and some basic rights.  You might
consider doing that in the user model''s after_save callback.

The smart thing to do (because you can''t easily see this from the web
interface) would be to write the test first.

  def test_user_default_roles_created
    u = User.create :username =>"homer", :password=>1234
    # user should have only one role... guest
    assert_equal 1, u.roles.size
    # more code would go here to actually verify that the "guest" role
is
assigned to the user by the callback
  end


Doing that first helps me think about the end result and also helps me
decide if that is in fact the way I want to do it... maybe I don''t want
to
assign the role automatically... maybe I want something else to happen
instead.

Just my thoughts... I''m doing my best to convert more people to TDD and
am
working on a tutorial that helps explain how I use it to build apps.... The
Peepcode one rocks too so check that out as well.


On 11/30/06, Faisal N Jawdat
<faisal-yPPMdBsEuU/QT0dZR+AlfA@public.gmane.org>
wrote:
>
>
> On Nov 30, 2006, at 6:31 PM, Taylor Strait wrote:
> > Rails went from fun ActiveRecord magic tricks to a world of
''TEST
> > FAILED.''
>
> some people take the approach of stubbing all the tests you can think
> of before you write the code (def test_should_incinerate_pie; end),
> making sure the code more or less works, then running the existing
> test suite to verify that you haven''t broken anyway, and last,
> actually writing the contents of all those tests you stubbed out.  it
> isn''t as pure as tdd, but it does accomplish some of the major
goals
> (think about what should work and how, and be able to validate that
> you have no regressions).
>
> -faisal
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Brian Hogan wrote:
> It forces you to think about your logic twice.
I hate that part. I just want to claw my way from the submit_tag to the 
database and then collapse.

However, I don''t want to have to do that again and again and again. I
want
my own workflow to be DRY.

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!!


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Faisal N Jawdat wrote:
> some people take the approach of stubbing all the tests you can think
> of before you write the code (def test_should_incinerate_pie; end),
> making sure the code more or less works, then running the existing
> test suite to verify that you haven''t broken anyway, and last,
> actually writing the contents of all those tests you stubbed out.  it
> isn''t as pure as tdd, but it does accomplish some of the major
goals
> (think about what should work and how, and be able to validate that
> you have no regressions).
The goal is to make very few edits between test runs, and always predict the 
result of each test run. Either predict that all the tests pass, or predict 
what kind of error diagnostic you will see.

Don''t edit for a long time then expect tests to pass.

Configure your editor - whatever it is - to run all your tests when you hit 
F5.

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!!


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Even better... install ZenTest

gem install ZenTest

autotest --rails

Tests run when you save the corresponding file.  Makes it almost too easy.

On 11/30/06, Phlip <phlip2005-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
>
> Faisal N Jawdat wrote:
>
> > some people take the approach of stubbing all the tests you can think
> > of before you write the code (def test_should_incinerate_pie; end),
> > making sure the code more or less works, then running the existing
> > test suite to verify that you haven''t broken anyway, and
last,
> > actually writing the contents of all those tests you stubbed out.  it
> > isn''t as pure as tdd, but it does accomplish some of the
major goals
> > (think about what should work and how, and be able to validate that
> > you have no regressions).
>
> The goal is to make very few edits between test runs, and always predict
> the
> result of each test run. Either predict that all the tests pass, or
> predict
> what kind of error diagnostic you will see.
>
> Don''t edit for a long time then expect tests to pass.
>
> Configure your editor - whatever it is - to run all your tests when you
> hit
> F5.
>
> --
>   Phlip
>   http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Jeff Pritchard wrote:
> The job before us involved creating both a new XML based GUI layer and
> also the glue and support code needed to hook that to an existing set of
> "middleware" (this is phone UI stuff).  I was doing the
glue/support
> code, and he was in charge of writing the XML stuff.  He helped me
> realize that the easy way for him to communicate just what he needed
> from my part, was to write a test.  He would send me an email something
> to the effect of "I just added a test for BLAH", and then I would
go off
> and write some stuff that makes his test pass, then he would hook that
> up to his XML and goodness would happen.
Nice - tests to define internal interfaces.

Note that fix requests to the Rails and related code repositories these days 
typically come with failing test cases.
> And because of the TDD approach, every little hunk of the project works
> perfectly (within the limits of the requirements we have defined -- i.e.
> the tests we have written) as we go, so there just isn''t any of
the old
> way of "OK, it''s feature complete -- in a few months we
should have some
> of it actually working right".
Shhhh! We need to keep that part a secret from the competition.

The few of them without pointy-haired bosses!

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!! 


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Brian Hogan wrote:
> Even better... install ZenTest
>
> gem install ZenTest
>
> autotest --rails
>
> Tests run when you save the corresponding file.  Makes it almost too easy.
My command line:

trigger ''rake recent'' `find test -name \\*.rb` app/*/*.rb 
app/views/*/*.rhtml

The utterly ugly and distastefully hacked-together contents of trigger are 
below my sig.

Any editor, folks. Any editor. I don''t even need to look at the console
to
hear the results. If the punk rock ain''t up too loud!

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

#!/usr/bin/env ruby


 #  lazy-loop until a file changes, then run a command


def syntax()
    puts ''syntax: trigger "command...args" files...''
    exit 1
end

#  TODO  support **

syntax()  if 0 == ARGV.size

command = ARGV.shift
$fileTimes = {}


def anyFileChanged()
    anyChanged = false

    ARGV.each do |fn|  #  TODO  option to do Dir here
        begin
          mod = File.mtime(fn)
          anyChanged = true  if $fileTimes[fn] != mod
          $fileTimes[fn] = mod
        rescue
          puts $!
          sleep 2
        end
    end

    return anyChanged
end


anyFileChanged()  #  prime the pump

while true
    sleep 0.333
    if anyFileChanged()
        got = system(command)

        sound  = got ?  ''drumloop.wav'' :  
''jaguar.wav''

        weWin32 = RUBY_PLATFORM.include?(''mswin32'')

        if weWin32
            system(''"C:\\Program Files\\Windows Media
Player\\mplayer2.exe"
/play /close s:\\bin\\'' + sound)
        else
            system(''aplay ~/bin/'' + sound)
        end

    end
end


#One way is to use Win32API:

SND_MEMORY   = 0x00000004   # from "mmsystem.h"
SND_FILENAME = 0x00020000

def playSound()

  pPlaySound = Win32API.new("winmm", "PlaySound",
[''P'', ''L'', ''L''],
''I'')

  # play from file:
  pPlaySound.call("C:/your/sound.wav", 0, SND_FILENAME)

# play from memory:
  #wav = File.open("C:/your/sound.wav", File::RDONLY) {|f| f.binmode; 
f.read }
  # PlaySound.call(wav, 0, SND_MEMORY)

end


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

That''s pretty wild.  I dig it.

On 11/30/06, Phlip <phlip2005-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
>
> Brian Hogan wrote:
>
> > Even better... install ZenTest
> >
> > gem install ZenTest
> >
> > autotest --rails
> >
> > Tests run when you save the corresponding file.  Makes it almost too
> easy.
>
> My command line:
>
> trigger ''rake recent'' `find test -name \\*.rb` app/*/*.rb
> app/views/*/*.rhtml
>
> The utterly ugly and distastefully hacked-together contents of trigger are
> below my sig.
>
> Any editor, folks. Any editor. I don''t even need to look at the
console to
> hear the results. If the punk rock ain''t up too loud!
>
> --
>   Phlip
>   http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
>
> #!/usr/bin/env ruby
>
>
> #  lazy-loop until a file changes, then run a command
>
>
> def syntax()
>     puts ''syntax: trigger "command...args"
files...''
>     exit 1
> end
>
> #  TODO  support **
>
> syntax()  if 0 == ARGV.size
>
> command = ARGV.shift
> $fileTimes = {}
>
>
> def anyFileChanged()
>     anyChanged = false
>
>     ARGV.each do |fn|  #  TODO  option to do Dir here
>         begin
>           mod = File.mtime(fn)
>           anyChanged = true  if $fileTimes[fn] != mod
>           $fileTimes[fn] = mod
>         rescue
>           puts $!
>           sleep 2
>         end
>     end
>
>     return anyChanged
> end
>
>
> anyFileChanged()  #  prime the pump
>
> while true
>     sleep 0.333
>     if anyFileChanged()
>         got = system(command)
>
>         sound  = got ?  ''drumloop.wav'' :  
''jaguar.wav''
>
>         weWin32 = RUBY_PLATFORM.include?(''mswin32'')
>
>         if weWin32
>             system(''"C:\\Program Files\\Windows Media
> Player\\mplayer2.exe"
> /play /close s:\\bin\\'' + sound)
>         else
>             system(''aplay ~/bin/'' + sound)
>         end
>
>     end
> end
>
>
> #One way is to use Win32API:
>
> SND_MEMORY   = 0x00000004   # from "mmsystem.h"
> SND_FILENAME = 0x00020000
>
> def playSound()
>
>   pPlaySound = Win32API.new("winmm", "PlaySound",
[''P'', ''L'', ''L''],
''I'')
>
>   # play from file:
>   pPlaySound.call("C:/your/sound.wav", 0, SND_FILENAME)
>
> # play from memory:
>   #wav = File.open("C:/your/sound.wav", File::RDONLY) {|f|
f.binmode;
> f.read }
>   # PlaySound.call(wav, 0, SND_MEMORY)
>
> end
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Brian Hogan wrote:
> That''s pretty wild.  I dig it.
With a little more work I''m going to get it to say "Ni!" when
it passes and
"Bad Zoot!" when it fails.

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!!


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On 11/30/06, Taylor Strait
<rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>
wrote:
>  As a beginning Rails developer it has really taken all the fun
> out of RoR development.  Is TDD so much better than writing methods and
> testing using a combination of the application interface and Navicat to
> check the database?
Yes.

You are doing e-commerce, not an AJAX chat application or Blog on Rails.
So in theory there is money on the line. I haven''t read the book, or
any
opinions on it, but it''s hardline approach to TDD in the context of
e-commerce automatically raises my opinion of it.

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

The more I test the less I''m afraid of having my application falling 
down like a sand castle. I''ve done many sand castles before, none felt 
down because I''ve been lucky.

Thanks to TDD (and Rails, because I''ve spend so many years trying to 
setup TDD under J2EE with tools like Cactus without any result - I 
thought I was stupid) I''m still earning my money developing
applications
for customers but WITH JOY !!!

PLUS : Tests are now a commercial argument I use to convince my 
clients/customers to choose me !

I''m still a dwarf at Agile development and TDD but compared to most of 
the others companies/individuals here I''m a step ahead. And I dare to 
say "I DO AGILE DEV, I DO TDD" every time I have the opportunity...

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

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

nuno wrote:
> The more I test the less I''m afraid of having my application
falling
> down like a sand castle. I''ve done many sand castles before, none
felt
> down because I''ve been lucky.
>
> Thanks to TDD (and Rails, because I''ve spend so many years trying
to
> setup TDD under J2EE with tools like Cactus without any result
Good lord I thought I was thru with this thread...

My last big project had a major issue (translation: failure) attempting to 
get Cactus working on a Tomcat project. I had more success TDDing CIAO, but 
its patron (a highly respected _professor_ of programming) eventually called 
me a "lunatic" because I kept asking weird questions on their mailing
list.
I got CIAO (an advanced form of CORBA)completely under control...

...but I couldn''t even _install_ Cactus. Each time I tried to configure
things, I would get stuck in some hideous error condition. Then, for 
example, I couldn''t tell what the error was because I couldn''t
turn on
logging, because the system wasn''t configured just right. That sick
joke of
a system lead to this page:

http://c2.com/cgi/wiki?ConfigurationHell

That''s the anti-Convention over Configuration - refusing to convene 
_anything_, in fear that the user might override a default.

Someone will have to put a gun to my head to get me to write automated tests 
for Tomcat again, but if they do, I am ready: With Watir...

...and with a trick or two that are currently up my sleeve, folks! ;-)
> PLUS : Tests are now a commercial argument I use to convince my
> clients/customers to choose me !
Try "I can deploy continuously and deliver daily"...

Richard Conroy wrote:
> You are doing e-commerce, not an AJAX chat application or Blog on Rails.
> So in theory there is money on the line. I haven''t read the book,
or any
> opinions on it, but it''s hardline approach to TDD in the context
of
> e-commerce automatically raises my opinion of it.
TDD-ing the GUI Layer is very hard, so we have an excuse to slack off on it.

Until someone fixes that. ;-)

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!! 


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Fri, Dec 01, 2006 at 03:40:54AM -0800, Phlip wrote:
> TDD-ing the GUI Layer is very hard, so we have an excuse to slack off on
it.
> 
> Until someone fixes that. ;-)
I''ve heard of people doing TDD with Selenium. I''m not
convinced that
having to use a browser to run your tests is not more trouble than it''s
worth especially for TDD - but people more clever than me seems to like
it.

-- 
Cheers,
- Jacob Atzen

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Jacob Atzen wrote:
> I''ve heard of people doing TDD with Selenium. I''m not
convinced that
> having to use a browser to run your tests is not more trouble than
it''s
> worth especially for TDD - but people more clever than me seems to like
> it.
Tip: Can we think of ways to TDD the GUI Layer without creating all of a web 
server, browser, DOM, etc.?

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!! 


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On 12/1/06, Jacob Atzen <jacob-4U2y0bnePT5NzRJJ8cAMrg@public.gmane.org>
wrote:
>
> On Fri, Dec 01, 2006 at 03:40:54AM -0800, Phlip wrote:
> > TDD-ing the GUI Layer is very hard, so we have an excuse to slack off
on it.
> >
> > Until someone fixes that. ;-)
>
> I''ve heard of people doing TDD with Selenium. I''m not
convinced that
> having to use a browser to run your tests is not more trouble than
it''s
> worth especially for TDD - but people more clever than me seems to like
> it.
I have some experience with trying to do automated testing at a higher
level than unit testing.

1 - they are much harder to write
2 - it is more difficult to get these tests to exercise all of your
code branches
3 - the tests are very brittle with regard to feature changes etc.

TDD really requires Unit Testing. Its the only cheap way to get good test
coverage, and its the good test coverage that provides the foundation for
all of the other good TDD practices.

On top of this, you can get functional tests, acceptance tests etc. The
closer you get to the user, and the further from the ''coal
face'', it starts
to get much more appropriate to use tools like Selenium & WATIR.
These tools *complement* your TDD arsenal, but given a choice, you
simply can''t get TDD benefits without low-level unit testing.

Selenium & WATIR are great tools, but if they are your only tools,
then you are not doing TDD.

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

You don''t need the -rails option, the latest version automatically
recognizes the Rails project and runs all the tests.

How do I make my terminal show failures in red? I am on Mac. TIA.

On 11/30/06, Brian Hogan <bphogan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> Even better... install ZenTest
>
> gem install ZenTest
>
> autotest --rails
>
> Tests run when you save the corresponding file.  Makes it almost too
--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Fri, Dec 01, 2006 at 08:30:55AM -0500, Bala Paranj wrote:
} 
} You don''t need the -rails option, the latest version automatically
} recognizes the Rails project and runs all the tests.
} 
} How do I make my terminal show failures in red? I am on Mac. TIA.

gem install turn

Then require ''turn'' in test_helper.rb

--Greg


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

>
> gem install turn
>
> Then require ''turn'' in test_helper.rb
>
> --Greg

Will this work on iterm also?


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

The view must be dumb. Move all the logic into helpers, now you can test
your helpers. There is a helper_test plugin that makes it easy to test.
Check out:
http://nubyonrails.topfunky.com/articles/2006/04/07/test-your-helpers


>
> Tip: Can we think of ways to TDD the GUI Layer without creating all of a
> web
> server, browser, DOM, etc.?
>
> --
> Phlip
> http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
>
>

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Dec 1, 2006, at 9:06 AM, Gregory Seidman wrote:
> gem install turn
>
> Then require ''turn'' in test_helper.rb
does this require some particular TERM setting?

-faisal



--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Fri, Dec 01, 2006 at 11:11:02AM -0500, Bala Paranj wrote:
} >
} > gem install turn
} >
} > Then require ''turn'' in test_helper.rb
} >
} > --Greg
} 
} Will this work on iterm also?

I would expect so, but I don''t use iterm. Try it out.

--Greg


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Fri, Dec 01, 2006 at 11:30:00AM -0500, Faisal N Jawdat wrote:
} 
} On Dec 1, 2006, at 9:06 AM, Gregory Seidman wrote:
} > gem install turn
} >
} > Then require ''turn'' in test_helper.rb
} 
} does this require some particular TERM setting?

I''ve only used it on an xterm, and it works just fine in that. I
recommend
trying it out and, if it doesn''t work, sending a message to the author
(not me!).

} -faisal
--Greg


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On 12/1/06, Nathan Leach
<nathanoleach-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> I am really interested in Behavior-Driven Development (BDD) with Rails.
> Rspec seems excellent for Ruby BDD and I have just started toying with
> the Rpsec on Rails plugin to run through some simple examples.
>
> My question is, is it possible to implement Rspec on Rails for an
> existing Rails project and if so how?
>
> Have a bunch of pre-existing projects that I would like to use Rspec on
> Rails on and I would hate to have to manually create all the nice
> directories and files that Rspec on Rails does when you use it from the
> beginning.  Any help would be appreciated.
>
> Thanks,
> Nathan
Nathan,

I''m in a similar position - a 6 month old app that I can''t
just drop
all the current tests and go with rspec.  I''m considering using
test/spec to start switching to BDD on a spec by spec basis.  It
integrates with test/unit and doesn''t require translating old tests to
specs.

info here:
http://chneukirchen.org/blog/archive/2006/10/announcing-test-spec-0-2-a-bdd-interface-for-test-unit.html

- rob
-- 
http://www.robsanheim.com
http://www.seekingalpha.com
http://www.ajaxian.com

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

I am really interested in Behavior-Driven Development (BDD) with Rails.
Rspec seems excellent for Ruby BDD and I have just started toying with
the Rpsec on Rails plugin to run through some simple examples.

My question is, is it possible to implement Rspec on Rails for an
existing Rails project and if so how?

Have a bunch of pre-existing projects that I would like to use Rspec on
Rails on and I would hate to have to manually create all the nice
directories and files that Rspec on Rails does when you use it from the
beginning.  Any help would be appreciated.

Thanks,
Nathan


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Anyone who wants their joy of TDD killed by Rails, dead, by an expert, 
please ping me privately. I have a shot at writing something up on this, and 
I need feedback and numbers first.

Working title, oh, I dunno, maybe...

  --> Test First Ajax <--

;-)

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!! 


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Rob,

Cool, thanks for the link.  Looks like just what I needed.

Nathan

On Fri, 2006-12-01 at 12:44 -0600, Rob Sanheim wrote:


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Nathan,

  > My question is, is it possible to implement Rspec on Rails for an
  > existing Rails project and if so how?

Give a try to the simply_bdd plugin.
  http://svn.techno-weenie.net/projects/plugins/simply_bdd/README

It makes using RSpec a lot easier: you run rspec code like normal
tests (see the example in the README page), and it works fine with
autotest.

Not shown in the README example is the need to use
   require ''spec''
to access the should_** magic.


Example:

file: test/unit/a_user_test.rb
 require File.dirname(__FILE__) + ''/../test_helper''
 require ''spec''

 context "A User with no name" do
    def setup
      @user = User.new
    end

    specify "should be invalid" do
      # assert !@user.valid?        # std way
      @user.should_not_be_valid # rspec way
    end
 end

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

I''ve done it both ways now, and prefer TTD for many reasons. 
Here''s
some of them:

[Benefit #1]
The benifit of TDD is more than a thoroughly tested application.

-Reducing Under-design:  When you miss the mark by not implementing 
requirements (either through omissions in the requirements or not 
fulfilling them).  Bugs crop up as a result.

-Reducing Over-design:  When you surpass the minimal work necessary to 
fulfill the requirements.  The more code you have the more potential 
there is for additional bugs.

Both of these add time to a project -- translating to higher project 
cost.

When you write a unit test first, you follow up by running it and 
watching it fail.  Next you write code until it passes.  Then reduce the 
code so it is as clean and minimalist as possible to pass the test.
[/Benefit #1]

[Benefit #2]
You are already doing unit testing in a manner of speaking.  You are 
just not doing it efficiently or consistently.  When you write code you 
it there thinking a lot about how to implement it.  Then consider the 
broader implications the modifications have.  This consumes time -- 
lots of it.  And you still don''t know what will occur.  You just have
to
make your best guess.

When the coding phase begins, you write code and test it iteratively or 
you wait to the end and hope it isn''t too screwed up.  Either way you 
test it over and over.  Automated Unit testing in TTD speeds things up 
by taking you out of the loop and makes testing more consistent 
(obviously).

You spend a lot of time writing them, but you never account for just how 
many times they get executed after you''re done.  Trust me,
That''s a big
number.  So, take the amount of time it takes for [you] to sit there 
testing your code and multiply it by the number of times the test cases 
execute.  Now follow the resulting conclusion ...
[/Benefit #2]

[Benefit #3]
INSTANT FEEDBACK

Relating to the previous benefit is comfort.  How many times have you 
been asked if you can make a change and answered, "No Problem"  while 
feeling concretely certain about your answer?

When you have a robust test harness complimenting your application, you 
stop worrying about what you are about to break in the code.  Just make 
you stinking changes and let the test harness work about the rest of the 
problem.

SPEED
Not worrying about the broad implications of code modifications makes 
you write write code a a break-neck speed.  :o)
[/Benefit #3]

[Benefit #4]
Documenting what the code does and how it does it.

One of the unforeseen products of TDD was the documentation it produced. 
It does a great job documenting how a piece of code is expected to be 
used.  If you think about what a repository of knowledge it becomes, 
what a benefit that becomes!  Nuff said!
[/Benefit #4]

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

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Cody Skidmore wrote:
> just not doing it efficiently or consistently.  When you write code you 
> it there thinking a lot about how to implement it.  Then consider the 
Sorry folks!  That should be, "When you write code you sit ther...."

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

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

You could always ignore the TDD portions of the book. Build an
e-commerce application with zero tests and I wish you luck. Our company
has made good...err...great money for almost two years because of
applications that had little to zero test coverage and the developers
clients got fed up with the random bugs in the application and wanted a
second opinion.

One of the very first things that I encourage potential clients that
have existing developers to do is to get the output of... rake stats.

This isn''t as uncommon to see as many of us would like.

Code LOC: 9473     Test LOC: 575     Code to Test Ratio: 1:0.1

(real output from a past client that came to us...)

Good luck!

-Robby


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Robby Russell wrote:
> This isn''t as uncommon to see as many of us would like.
>
> Code LOC: 9473     Test LOC: 575     Code to Test Ratio: 1:0.1
Ahem:

  Code LOC: 1598     Test LOC: 1577     Code to Test Ratio: 1:1.0

And note that the higher the Test LOC gets, the more ability you have to 
squeeze down on the Code LOC, and keep it low.

Low line counts are good, folks!

-- 
  Phlip
  http://www.greencheese.us/ZeekLand <-- NOT a blog!!!


--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On 12/1/06, Alain Ravet
<alain.ravet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> Nathan,
>
>   > My question is, is it possible to implement Rspec on Rails for an
>   > existing Rails project and if so how?
>
> Give a try to the simply_bdd plugin.
>   http://svn.techno-weenie.net/projects/plugins/simply_bdd/README
>
> It makes using RSpec a lot easier: you run rspec code like normal
> tests (see the example in the README page), and it works fine with
> autotest.
>
> Not shown in the README example is the need to use
>    require ''spec''
> to access the should_** magic.
>
>
> Example:
>
> file: test/unit/a_user_test.rb
>  require File.dirname(__FILE__) + ''/../test_helper''
>  require ''spec''
>
>  context "A User with no name" do
>     def setup
>       @user = User.new
>     end
>
>     specify "should be invalid" do
>       # assert !@user.valid?        # std way
>       @user.should_not_be_valid # rspec way
>     end
>  end

Related and worht reading:

Related to these options:

http://weblog.techno-weenie.net/2006/11/24/test-spec-kicks-simply_bdds-ass

- rob


-- 
http://www.robsanheim.com
http://www.seekingalpha.com
http://www.ajaxian.com

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On 12/1/06, Nathan Leach
<nathanoleach-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> I am really interested in Behavior-Driven Development (BDD) with Rails.
> Rspec seems excellent for Ruby BDD and I have just started toying with
> the Rpsec on Rails plugin to run through some simple examples.
>
> My question is, is it possible to implement Rspec on Rails for an
> existing Rails project and if so how?
>
> Have a bunch of pre-existing projects that I would like to use Rspec on
> Rails on and I would hate to have to manually create all the nice
> directories and files that Rspec on Rails does when you use it from the
> beginning.  Any help would be appreciated.
When you first install the RSpec on Rails plugin, your existing tests
won''t run.  Don''t worry though, there''s a very easy
workaround!
http://rubyforge.org/tracker/index.php?func=detail&aid=6629&group_id=797&atid=3149
 read through that, I''ve got a simple explanation.  It''s
really really
easy so check it out.

You can use RSpec along with any standard Rails tests.  This is nice
if you want to install something like the restful_authentication
plugin, but use RSpec to drive your design.  Use my workaround above,
and rake will automatically run all your tests and specs for you.

The only thing that you''ll have to create is spec files for your
existing code.  I''d suggest generating an rspec_model and
rspec_controller to get the directory structure and a template spec
file to work from.

Also, we have an RSpec list that you should check out.  Go to the
project page and sign up!

Pat

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

On Fri, Dec 01, 2006 at 09:06:58AM -0500, Gregory Seidman
wrote:
> 
> On Fri, Dec 01, 2006 at 08:30:55AM -0500, Bala Paranj wrote:
> } 
> } You don''t need the -rails option, the latest version
automatically
> } recognizes the Rails project and runs all the tests.
> } 
> } How do I make my terminal show failures in red? I am on Mac. TIA.
> 
> gem install turn
> 
> Then require ''turn'' in test_helper.rb
To get coloring you also need the facets gem:

gem install facets

From the gem description:

        If you have the ''facets'' gem installed, then TURN
output will be
        displayed in wonderful technicolor (but only if your terminal
        supports ANSI color codes).

-- 
Cheers,
- Jacob Atzen

--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Thank you Jacob. After I installed facets now the turn seems to work.
I see green, red and other colors to highlight autotest window. Very
cool and easy to spot problems!
> To get coloring you also need the facets gem:
>
> gem install facets
>
> From the gem description:
>
>         If you have the ''facets'' gem installed, then TURN
output will be
>         displayed in wonderful technicolor (but only if your terminal
>         supports ANSI color codes).
>
> --
> Cheers,
> - Jacob Atzen
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
 You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
-~----------~----~----~----~------~----~------~--~---