testing

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.

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? http://pastie.caboo.se/61451

-Nathan

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

Agile Web Development 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 Development" basically didn't fly. :wink: