TDD killing my joy of Rails

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. :wink:

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 A.

On 12/1/06, Jacob A. [email protected] 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. :wink:

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 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

Will this work on iterm also?

On Fri, Dec 01, 2006 at 08:30:55AM -0500, Bala P. 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

On Dec 1, 2006, at 9:06 AM, Gregory S. wrote:

gem install turn

Then require ‘turn’ in test_helper.rb

does this require some particular TERM setting?

-faisal

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

On Fri, Dec 01, 2006 at 11:11:02AM -0500, Bala P. 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

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

On 12/1/06, Nathan L. [email protected] wrote:

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

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 ←

:wink:


Phlip
Redirecting... ← NOT a blog!!!

On Fri, Dec 01, 2006 at 11:30:00AM -0500, Faisal N Jawdat wrote:
}
} On Dec 1, 2006, at 9:06 AM, Gregory S. 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

Rob,

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

Nathan

On Fri, 2006-12-01 at 12:44 -0600, Rob S. 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 [email protected]?        # std way
  @user.should_not_be_valid # rspec way
end

end

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]

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

Robby R. 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
Redirecting... ← NOT a blog!!!

Cody S. 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…”

On 12/1/06, Nathan L. [email protected] wrote:

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

On Fri, Dec 01, 2006 at 09:06:58AM -0500, Gregory S. wrote:

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 A.