All the time I hear that RoR has great testing enviroment.
Well, why I need tests? I test my webapp all the time - code a page and
than test it. So why I need that extra test - does it make some special
tests?
I am confused
pete
You should strive to make your tests automated wherever its realistic
to do so. Rails makes it easy to unit test your model and controller
code, and has functional testing to test your apps end to end
functionality too. Not testing your code properly is a form of
professional malpractice IMO.
Untested code is pretty worthless, tests ensures that your code is
behaving like it is specified, it allows your code for easy
refactoring.
On 7 November 2006 13:30, Pete wrote:
All the time I hear that RoR has great testing enviroment.
Well, why I need tests? I test my webapp all the time - code a page and
than test it. So why I need that extra test - does it make some special
tests?
I am confused
Well, there are plenty of literature on it (search for “Test Driven
Development”).
You see, in dynamic language like Ruby it is easy to break something
without even knowing it.
Tests allow to eliminate such errors (at least you will know that
something is broken). And it’s a
great advantage that Rails provides ready-to-use testing environment.
The situation you described (write, then test) is not gonna work,
because you will need to test all the pages
with all scenarios every time you make a change. If you test only one
page that you currently develop,
you can break some other page without even knowing it (e.g. changing
some model behaviour that will
break one of you pages).
On 11/7/06, Pete [email protected] wrote:
All the time I hear that RoR has great testing enviroment.
Well, why I need tests? I test my webapp all the time - code a page and
than test it. So why I need that extra test - does it make some special
tests?
Automated Unit Testing is a powerful technique in driving code quality
and
improving confidence in the code.
Developer Unit testing takes up your precious time, that could be used
for getting more coding done, or could be used for more involved testing
that really needs a human.
Automated Unit Testing by definition, works for free and in parallel
with
your day to day tasks.
Once you have used it, it is really difficult to go back. Without
Automated
Unit Tests there are developer activities like refactoring that you
simply
cannot do safely. You can afford to take risks during feature
development,
because you are more confident that unintended consequences can be
captured.
I would never by choice commence another project that didn’t inherently
use automated unit testing.
On 11/7/06, Matthijs L. [email protected] wrote:
Untested code is pretty worthless, tests ensures that your code is
behaving like it is specified, it allows your code for easy
refactoring.
That’s the big one for me. It’s usually pretty obvious when your code
is or isn’t working during the initial development. But when you come
back to it a month later to make a change, it’s so nice to have “rake
test” waiting to flag everything that just got broken.
– James
On Tue, Nov 07, 2006 at 11:30:00AM +0100, Pete wrote:
} All the time I hear that RoR has great testing enviroment.
} Well, why I need tests? I test my webapp all the time - code a page
and
} than test it. So why I need that extra test - does it make some
special
} tests?
} I am confused
Different languages and frameworks offer different tradeoffs, among them
being different safety nets.
C++ provides strong type safety in its duck typing (yes, the C++
templating
language supports duck typing) that guarantees (unsafe casting aside)
that
if your program compiles then there is code backing all method calls,
not
to mention excellent runtime performance. On the other hand, it allows
arbitrary memory access, requires manual memory management, requires
many
more lines of code as compared to a language like Ruby to accomplish
similar tasks, and the extent of the running code is fixed at compile
time
modulo explicit plugin interfaces.
There is still value to automated tests (and assertions!) in C++, but
many
of the sorts of tests that are important for Ruby code occur implicitly
at
compile time; the compiler is a static code analyzer, and the code
itself
provides sufficient information to support this analysis.
Ruby is sufficiently dynamic in a number of senses (e.g. loading code
can
alter existing code paths), which precludes such static analysis. To
regain
a level of certainty that the code works after a seemingly minor change,
one writes tests that assert preconditions and postconditions and
results
and failure modes and such. Running those automated tests is similar to
performing the static analysis that the C++ compiler performs. While it
is
possible to run Ruby code that has not undergone such automated testing,
it
is best to consider it similar to trying to run C++ code without
compiling
it. (Sadly, I am routinely guilty of this.)
} pete
–Greg
Test driven development is the next big fad in development
methodologies (Waterfall, Extreme, Agile, etc…) It’s definitly one
way of doing things, but it isn’t a comprehensive justification for
unit testing.
Programming is about getting results and results are measured in Time
to Production, Quality of Application and Cost to Produce. Every bug
that makes it into production costs much more than a bug that is caught
in code (especially for a well used application).
All forms of testing are an attempt to verify that things are working
correctly before users actually hit the app. For a new application
testing is less necessary, but as an application becomes more widely
used, every change has the potential of messing something up (maybe
something completely unrelated to the change itself).
So for a short “once and done” project unit testing may be overkill,
although it might also help to ease nerves.
For a long term application that will be maintained over years and have
a large user base, test now and test often. The more automated that
testing is, the less time you’ll have to spend poking through long
forgotten features to make sure everything is still hunky dory.
Pete wrote:
All the time I hear that RoR has great testing enviroment.
Well, why I need tests? I test my webapp all the time - code a page and
than test it. So why I need that extra test - does it make some special
tests?
I am confused
A car has brakes not so it can stop, but so it can safely go fast.
If you write many pages, and then add new features to all of them, you
might break something. So if you have a lot of pages, you might have
manually retest everything, to avoid releasing bugs. Manually retesting
slows you down.
So if your car has no brakes, you must drive very slow, to avoid
trouble at intersections!
With tests, you can rapidly change code long after you wrote it. The
tests will tell you when to stop changing, if something breaks.
Then, instead of debugging, you can often use Undo to revert your
change. Then all the tests pass again, and you can try a smaller
change.
People who use Test-Driven Development always report they spend much
less time debugging.
–
Phlip
Pete-
I thought the same way and had the same questions for 4 months of
writing Rails code before I finally saw the light. Now I realize that
if I had been following a good testing methodology, those 4 months of
code might have been completed in 6 weeks or so.
You say “I test my webapp all the time - code a page and then test
it”. What you are actually doing is ‘debugging’ - you’re comparing
the behavior of your app to the idea you have in your head of what the
app is supposed to do. With testing, the focus gets much smaller -
not ‘the app is broken’, but ‘that last change made the user
authentication fail because the password hash was other than
expected’. You don’t have to debug, you don’t have to guess, you just
have to fix the part that is broken, safe in the knowledge that your
tests won’t let you unknowingly introduce more bugs.
And here’s the part that really blew my mind: once you figure out how
testing works, you’ll find yourself writing a test before you write
the code that is being tested. This does 2 things - first it lets you
know, the second you are done writing the code, whether what you wrote
does what you intended or not, and second it lets you know when you’re
done writing the code. This doesn’t mean you won’t clean it up or
refactor… in fact, testing means that you can refactor safely,
because if the refactored code still passes the tests it has the same
functionality as the original code. But in the meantime the tests let
you know when the functionality of a section of code is complete, so
you can move on to adding more functionality without getting bogged
down in endless tweaks.
The ‘autotest’ part of ZenTest (
zentest | software projects | by ryan davis ) does continuous
automated testing… every time you change a file, it runs the tests
that are affected by that file. You get almost real-time feedback
about what problems your changes have introduced… and not just
“there is a problem”… if you wrote your tests correctly they will
show you what broke on which line, and you can fix it immediately.
Read “Test First, by Intention” (
http://www.rubycentral.com/articles/pink/index.html ). Then if you
want to see good tests in their native environment, look through
technoweenie’s code… Beast is a good starting place (
http://svn.techno-weenie.net/projects/beast/trunk/test/unit/ ). The
Agile book ( http://pragmaticprogrammer.com/titles/rails2/index.html )
has a good chapter on testing that unfortunately, due to the
constraints of the book format, doesn’t show you the best testing
methodology (they sort of tack it on at the end, reinforcing the
perception that it is ‘more work’) but it is a good introduction to
testing in Rails.
I know it sounds like more work, but I swear to you as a fellow
doubter that it makes more sense than any other programming
methodology I have ever seen. I code faster and more confidently than
I did before I started testing, and I wouldn’t even consider starting
another project without testing.
- foobario
Hi –
On Tue, 7 Nov 2006, Pete wrote:
All the time I hear that RoR has great testing enviroment.
Well, why I need tests? I test my webapp all the time - code a page and
than test it. So why I need that extra test - does it make some special
tests?
I am confused
See various other comments on the merits of rigorous testing. I’ll
throw in a bit of a footnote, which is that the question has arisen in
my mind about testing things that have already been tested… What I
mean is that, for example, ActiveRecord has a pretty serious test
suite. So if I do:
validates_size_of :comment, :maximum => “100”
I sometimes wonder whether I really need a test like:
def test_size_of_comment
@thing.comment = “hello” * 21
assert(!@thing.valid?)
end
or whatever. The method I’m using, validates_size_of, already has
unit tests. On the other hand, one could view it as testing to make
sure the validation didn’t accidentally get deleted from the model
file. But then, how does one test to make sure that one didn’t forget
to put “test_” at the beginning of every test? And so on.
In sum, we live with a horizon beyond which there is no testing. The
question is: where is that horizon? Perversely, perhaps, I find this
as interesting a question as any in the test realm.
David
–
David A. Black | [email protected]
Author of “Ruby for Rails” [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB’s Weblog) [2] | Co-director, Ruby Central, Inc. [4]
[1] Ruby for Rails | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com | [4] http://www.rubycentral.org
Aaron wrote:
So for a short “once and done” project unit testing may be overkill,
although it might also help to ease nerves.
If you use a system like Lotus Notes, where automated tests are nearly
impossible, then that formula applies.
In a test-rich system like Rails, TDD devolves into simply writing
everything twice, once as a test case and again as production code.
It’s usually only a bit more typing.
When it isn’t - when you must research how to test something - then
your formula takes effect. Untested features can rely on “herd
immunity” to resist bugs.
Saying some Rails projects don’t need TDD is like telling an accountant
that some small business don’t need double-entry bookkeeping.
–
Phlip
Regarding tests on validations, see Luke R.'s excellent discussion
at:
http://www.lukeredpath.co.uk/2006/8/29/developing-a-rails-model-using-bdd-and-rspec-part-1
The part I’m specifically referring to is “avoid meaningless tests.”
With
that said, it’s important to note that when you write
validates_something_or_other, you are imposing a constraint on your
model.
At some point in the future, you might write other code that is in
conflict
with this constraint. My perspective is not to test whether the
validation
really validates, but that expected data actually is validated the way
you
want.
Does that make sense?
Steve
dblack wrote:
tests?
I sometimes wonder whether I really need a test like:
to put “test_” at the beginning of every test? And so on.
Author of “Ruby for Rails” [1] | Ruby/Rails training & consultancy [3]
DABlog (DAB’s Weblog) [2] | Co-director, Ruby Central, Inc. [4]
[1] Ruby for Rails | [3] http://www.rubypowerandlight.com
[2] http://dablog.rubypal.com | [4] http://www.rubycentral.org
–
View this message in context:
http://www.nabble.com/-Rails--why-I-need-testings-in-rails--tf2587902.html#a7249268
Sent from the RubyOnRails Users mailing list archive at Nabble.com.