Hello,
I'm wondering why I should use Selenium if I am already testing my application using functional and integration tests? Don't Selenium tests merely test the same functionality?
Thanks, Ruben
Rails integration tests can't test anything but the most basic HTML and full request cycles. They also cannot tell you if your site works on Firefox and not IE.
Use Selenium to test things like:
* Ajax calls * Effects * Workingness on multiple browsers * Site usability
Jason
Rails integration tests can't test anything but the most basic HTML and full request cycles. They also cannot tell you if your site works on Firefox and not IE.
To elaborate on that, when you're doing integration/functional tests
there is no browser involved, therefore you cannot possibly test
anything that happens in the browser. For example you can test that
when you make a certain request some rjs is generated to update a
certain div, but you can't test that the div in question actually
exist. You also cannot test any of your javascript.
Fred
Jason Roelofs wrote:
Rails integration tests can't test anything but the most basic HTML and full request cycles. They also cannot tell you if your site works on Firefox and not IE.
Use Selenium to test things like:
* Ajax calls * Effects * Workingness on multiple browsers * Site usability
Isn't testing thru a server and browser to slow for TDD?
I would treat each failure as an opportunity to write a unit-level test - one that efficiently mocks the browser and server. I want an incremental test run to work in less than a few seconds, and I want an integration to take less than a minute. The hard, slow tests can run on a build server.
That's all well and good, but the fact is that if you want to test what the browser does, you need a browser. For example those tests are never going to tell you that you've got a typo in your javascript. Those tests are a lot slower, so you're probably not testing everything, just some common interactions.
Fred
I can't understand the confusion regarding selenium tests. Maybe the people are not running heavy ajax sites but if you have any significant ajax functionality, it becomes obvious why selenium tests are essential. "assert_select_rjs" just isn't going to cut it when you need to integration test the entire (list => new => create => list) process and its all ajax.
Frederick Cheung wrote:
I would treat each failure as an opportunity to write a unit-level test - one that efficiently mocks the browser and server. I want an incremental test run to work in less than a few seconds, and I want an integration to take less than a minute. The hard, slow tests can run on a build server.
That's all well and good, but the fact is that if you want to test what the browser does, you need a browser.
You need more than one!
For example those tests are never going to tell you that you've got a typo in your javascript.
assert_javascript works out of unit tests, by parsing the JavaScript. It can catch simply typos - and of course it should not attempt to evaluate that JS, or simulate a browser. Its job (like assert_rjs) is to detect that your production code has inserted the correct replacement values into the correct fields. assert_js_insert_html matches rjs.insert_html, assert_js_hide matches rjs.hide, etc.
Frederick Cheung wrote:
I would treat each failure as an opportunity to write a unit-level test - one that efficiently mocks the browser and server. I want an incremental test run to work in less than a few seconds, and I want an integration to take less than a minute. The hard, slow tests can run on a build server.
That's all well and good, but the fact is that if you want to test what the browser does, you need a browser.
You need more than one!
Indeed. Things like selenium grid, jsunit will run your tests on
multiple machines/browsers
For example those tests are never going to tell you that you've got a typo in your javascript.
assert_javascript works out of unit tests, by parsing the
JavaScript. It can catch simply typos - and of course it should not attempt to evaluate
that JS, or simulate a browser. Its job (like assert_rjs) is to detect that your
production code has inserted the correct replacement values into the correct
fields. assert_js_insert_html matches rjs.insert_html, assert_js_hide
matches rjs.hide, etc.
Neato, hadn't seen that before. It's still not an end to end test
though: it only tests a single interaction.