[Nitro] Test-based development
aidan at yoyo.org
Wed Feb 15 16:57:38 EST 2006
Lots of things to respond to in this thread, but I think overall you
guys are talking about 2 different levels of testing.
Rob is talking about unit testing the controller code; Eduardo is
talking about functional/integration testing. Both are valid and
necessary forms of testing, and are not mutually exclusive. For
example, I recently wrote a Rails app as part of my day job, and
wrote unit tests for the model and controllers. One of our testers
then did the functional/integration (pick your favourite term in this
case - everyone interprets test types as different things on
different days in different projects) testing which involved the
actual browser and pointing and clicking.
I think it would be really useful to create an automated way to unit
test both models and controllers. I think it would be as valuable to
integrate with Selenium in some way, not only to create the ability
to functionally test Nitro apps, but also so I can evangelise Nitro
to all the Selenium guys at ThoughtWorks - these guys are the sorts
of people with enough community clout to start generating real press
On 16/02/2006, at 2:59 AM, Eduardo Rocha wrote:
> 2006/2/15, Rob Pitt <rob at motionpath.com>:
>> I prefer the "fake sending" of forms and such as you can easily read
>> session, request, etc to see if everything went as it should. No
>> mechanize could be hacked to do this, but I do not see the
>> detraction of
>> only sending POST data as a method (Eduardo mentioned it's not taking
>> into account the real page) because you can visually very easily
>> see if
>> a page doesn't look like it should and would quickly notice
>> named fields (this isn't an error I've made before).
> I don't know if I understand you correctly, but I often fall into the
> mistake of passing the controller test (in Rails) and then I get an
> error testing in the browser, just because the form field names were
> diferent from the test. And yet I can do visually, I think it breaks
> the idea of TDD and automated tests.
>> On the other hand, it would be possible to create a "supervisor"
>> that managed both the app and mechanize or a thread within the app
>> ran mechanized on itself. I do not see there is a great benefit
>> considering the extra complexity, it's a small benefit but is it
>> the extra trouble to implement it like this?
> Concerning Watir/Selenium/Mechanize, my opinion is that features from
> Mechanize are very similar to Watir/Selenium, but are run outside the
> browser. I think this is not better or worse, because some people
> would prefer running this kind of test before running in browser. But
> with Mechanize you are using HTTP to test your app, which can slow
> down test (if one is that paranoic :) and it is not "that" pure.
> In Rails, for example, instead of passing parameters directly, it
> would be nice if we could start from the page (instead of a URL, in
> the case of Mechanize), and we associate the form fields with values
> (like Mechanize does, as well as Watir/Selenium).
>> Would like more opinions here.
>> On Wed, 2006-02-15 at 13:56 +0100, Kashia Buch wrote:
>>>> Is that really like a user browsing the site?
>>> I don't know how Watir/Selenium/Rails works in case of testing
>>> sites, but maybe one could use WWW::Mechanize to hack some web-
>>> page testing/traversing utility together.
>>> Mechanize works with the html, no "fake sending" of forms, you
>>> "fill 'em" like you normally would.
>>> and some additional Info for working with it:
>>> There doesn't seem so much information about it at all, but
>>> someone might be interested :)
>> Nitro-general mailing list
>> Nitro-general at rubyforge.org
> Nitro-general mailing list
> Nitro-general at rubyforge.org
More information about the Nitro-general