what’s the difference beween testin the rails way, or just using the the
browser?
I don’t like testing, I don’t know how, and it will take time for me to
learn it
if using the browser is the same as testing? then I’m not intrested in
testing with the framework
if it fails in the browser, it will fail in the test
if it fails in the test, it will fail in the browser
then what’s the difference ?
What I care more is not to fail in the browser, because that’s what it’s
for in the first place, to be browsed
if you can tall me a reason for testing, I will appreciate, that way
I’ll have a reason, and learn more happily
I am using only development for now, maybe in production is diffrent
gino wrote:
what’s the difference beween testin the rails way, or just using the the
browser?
The same amount of testing that could take 5 seconds in automate tests,
could take 5 days in manual tests.
If your testing cycle is faster, you can run the tests more often. Run
them
after every few code edits, and always try to predict their outcome.
That lets you know instantly when you make most mistakes. Not days
later.
And that lets you go faster, and take more risks.
http://www.faisal.com/docs/ror-list-faq.html
"Why do I need to write all these tests?
"You don’t need to, but it’s probably a good idea if you want your code
to
actually work. There is a technical answer and a philosophical reasons
to
test with Ruby (and, by implication, Rails).
"The technical answer is that Ruby, like all dynamic languages, does
more at
runtime and less at compile time. Accordingly, the compiler won’t catch
a
lot of the sorts of things that Java and C#'s compilers would. However,
a
test suite that exercises much of your code will tend to catch those
problems.
"The philosophical answer is that the Rails community tends to favor
Agile
methods of software development, and Agile methods tend to favor
test-heavy
(often test-first or test driven) programming practices due to their
flexibility.
“In any case, Rails comes with a built in testing framework, and Rails
developers tend to use the framework heavily.”
I don’t like testing, I don’t know how, and it will take time for me to
learn it
if using the browser is the same as testing? then I’m not intrested in
testing with the framework
I don’t like debugging. I don’t like having a bug, and not knowing even
what
module to look in to find it. I don’t like writing ‘p’ statements, then
watching the server transcript while poking around the user interface
looking for the bug. With tests, the odds of that kind of debugging goes
way
down.
This requires you learn to write the tests. Unit tests are very
important,
and one of the hardest situations to test is a website. Some frameworks
for
much simpler programs don’t have any unit test framework. Rails is
unique in
the programming industry for offering one of the best test frameworks in
the
world, and making it completely cover website testing.
This presents a challenge to a neophyte, and I don’t really blame you
for
finding it daunting. To learn testing for websites, even under Rails,
you
must work and work to figure out how to write those test cases, and then
you
must make them simple and flexible. Rails will help you, even as the
website
technology itself hinders you!
if it fails in the browser, it will fail in the test
if it fails in the test, it will fail in the browser
then what’s the difference ?
It fails in the test automatically, instantly.
It fails in the browser only after you click and click to force the
tested
situation. Even then, you might not notice the bug, because it might be
one
wrong variable in the database, not a big obvious problem on a web page.
Next, if you add a new feature X, it might break an old feature Y. Under
manual testing, you might only think to try X. Under automated testing,
the
tests you wrote for Y will still try to run, and they might report the
problem.
What I care more is not to fail in the browser, because that’s what it’s
for in the first place, to be browsed
if you can tall me a reason for testing, I will appreciate, that way
I’ll have a reason, and learn more happily
Here’s how it works, after you learn it. I write a test for a
super-simple
thing, such as submit a form:
def test_my_form
get :my_page
submit_form ‘my_form’
end
I run that and get it to fail. Then I add <form id=‘my_form’ …> to the
target page (usually inside a form_tag). Then the test passes.
Then I repeat for the next feature. To add an edit field to my form, I
make
the test query the button’s existence:
def test_my_form
login_as :franklyn
get :my_page
submit_form ‘my_form’ do
assert_equal ‘franklyn’, form[‘my_edit_field’], value
end
end
Then that fails, and I write the code to pass the test.
The result is I write each simple feature twice, once as a test and
again as
code. Each feature is simple, so this does not slow me down.
However, I rarely have to run the actual website now! That allows me to
spend all my time adding features, and almost no time manually running
the
browser just to look at each feature I add. Watching each test pass is
the
same as running the browser and looking at the feature. The tests become
my
view into what the website is doing. If I am curious about a feature, I
can
write another test for it, and I always make sure that writing more
tests is
easy.
I am using only development for now, maybe in production is diffrent
The best way to develop is with tests, early and often. If you delay
such
things until production, you will create a lot of nasty surprises.
Writing
tests at the same time as writing code is very easy, and adding tests
after
the code is extremely hard. Now is the time to develop good work habits.
Rails, and testing, will put anyone into the top 1% of all programmers
for
speed and efficiency. Many programmers, including old ones who think
they
know everything, still refuse to write tests. The wild success of the
Rails
platform shows how productive they can be.
–
Phlip
Test Driven Ajax (on Rails) [Book]
“Test Driven Ajax (on Rails)”
assert_xpath, assert_javascript, & assert_ajax
Wow, that’s a very comprehensive response. I’d just like to add that it
took
me a while to get into rails testing. I used to do testing for Java in
non-Web apps using jUnit, but couldn’t get into it in rails, especially
when
just experimenting to work out some of the details of my app. Now I’m on
actually writing my app properly, I’m using rSpec. This feels far more
natural than ordinary tests, and it promotes good testing practises. I
would
recommend trying rSpec for testing with. Here’s an example of a few
simple
specs to test relationships between models, combined with the code which
makes these specs pass. See how easy it is? Parked at Loopia
-Nathan
Thanks for your advices, I really appreciate it,
That’s what I needed to get myself going
rSpec is the next level of testing, so to speak, for those of us who
have
been practicing test driven development (TDD) for some time now. TDD
requires such a drastic change in development mind-set that I believe
it’s
very important for people to work on just TDD, get that down and
understand
the whys and hows, before jumping into the philosophy of behaviour
driven
design (BDD) of which rSpec is for.
Gino, if you have any specific questions about how to test parts of your
code, we will be glad to help.
Jason
Agile Web D. with Rails (
http://www.amazon.com/Agile-Development-Rails-Pragmatic-Programmers/dp/0977616630/ref=pd_bbs_sr_1/103-2079972-1383852?ie=UTF8&s=books&qid=1179161608&sr=8-1
)
Jason
I’m not sure I agree with that. I reckon rSpec is an ideal place for new
testers to start. The idea of specifying behaviour is what good tests
should
do anyway, and rSpec/BDD encourages this. Plus, syntactically, it’s a
smaller step to go from no tests to rSpec than to go from no tests to
Test::Unit or whatever, because rSpec is much more easy to read.
what book can easily explain how to test ror applications?
i just recently got ruby on rails e-commerce by Christian Hellsten, but
am still i think id need something a little more basic for
understanding.
thanks!
On May 14, 1:59 am, gino [email protected] wrote:
I don’t like testing, I don’t know how, and it will take time for me to
learn it
Shameless plug: many people have viewed my screencast on Test-First
Development with Rails and have said that it cleared up months of
confusion in only 90 minutes. Only $9 here:
http://peepcode.com/products/test-first-development
Geoffrey Grosenbach
http://peepcode.com
Agile Web D. with Rails
Note: “Agile” is an industry code-word. Authors picked it to
sugar-coat the real meaning: “We will bore you to tears with all sorts
of yacking about tests, instead of just writing sexy features.”
So calling it “Test-infected Web D.” basically didn’t fly. 
–
Phlip
http://c2.com/cgi/wiki?ZeekLand ← NOT a blog!!