Hi, This is my first post, I wanted to ask a quick question about "Bad Form" -- rather, am I doing something with Mechanise I shouldn''t be doing? Here''s the long and short of it - I am using Mechanize with Cucumber and RSpec to test a *ahem* Perl XML web service.. talk about technology soup, but I have it working quite well. I have an example project on GitHub that actually has a contrived Sinatra application to replicate testing a 3rd party system that you can only test the interface to. https://github.com/leehambley/webrat-mechanize-xml-rpc<https://github.com/leehambley/webrat-mechanize-xml-rpc/tree> The problem, or rather question is as such - I have, in my application''s test environment made use of PluggableParser, but overloaded it with the .default, and .html calls to parse everything as myown XMLParser class (copied almost verbatim from the CSVParser example in the RDoc) I have effectively rendered it as not a browser, by forcing it to treat anything that parses as XML as a WWW::Mechanize::File<http://mechanize.rubyforge.org/mechanize/WWW/Mechanize/File.html> rather than a WWW::Mechanize::Page<http://mechanize.rubyforge.org/mechanize/WWW/Mechanize/Page.html> - which I''m not sure about as an implementation. When the server sends a correct header (which isn''t in all parts...) then I do not need to set the .html parser to be XMLParser, it just recognizes the text/xml content-type header, and parses it to a file correctly... I guess, I have it all working, and we''re testing happily the web service, which is something our company does a lot of... so having Cucumber/Webrat and Mechanize all working this way is just... outstanding, it''s fantastic, but I don''t want to base my new suite of tests on a flawed principle! Thoughts welcome, or just ignore me, and I''ll sleep better knowing that I''ve confessed my sins to the internet! - Lee -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/mechanize-users/attachments/20090625/2bb01e8e/attachment.html>
Cheers for the sanity check matt, it does treat anything with a content-type text/xml header is processed correctly as a File, but text/html wasn''t! I''ve decided (with advice from the Cucumber people) that using MEchanize and Webrat to test an XML webservice is mad overkill, so I''m refactoring! - Lee 2009/6/25 Mat Schaffer <mat.schaffer at gmail.com>> Sounds cool to me. I guess the only thing that confused me a little bit was > the XML response to file object conversion which I though ive seen mechanize > already do. Other than that what you''re doing seems sound to me. Or at least > not totally off the wall :-) > > -mat > > Sent from my iPhone > > On Jun 25, 2009, at 5:36 PM, Lee Hambley <lee.hambley at gmail.com> wrote: > > Hi, > This is my first post, I wanted to ask a quick question about "Bad Form" -- > rather, am I doing something with Mechanise I shouldn''t be doing? > > Here''s the long and short of it - I am using Mechanize with Cucumber and > RSpec to test a *ahem* Perl XML web service.. talk about technology soup, > but I have it working quite well. > > I have an example project on GitHub that actually has a contrived Sinatra > application to replicate testing a 3rd party system that you can only test > the interface to. <https://github.com/leehambley/webrat-mechanize-xml-rpc/tree> > https://github.com/leehambley/webrat-mechanize-xml-rpc > > The problem, or rather question is as such - I have, in my application''s > test environment made use of PluggableParser, but overloaded it with the > .default, and .html calls to parse everything as myown XMLParser class > (copied almost verbatim from the CSVParser example in the RDoc) > > I have effectively rendered it as not a browser, by forcing it to treat > anything that parses as XML as a WWW::Mechanize::File<http://mechanize.rubyforge.org/mechanize/WWW/Mechanize/File.html> rather > than a WWW::Mechanize::Page<http://mechanize.rubyforge.org/mechanize/WWW/Mechanize/Page.html> - > which I''m not sure about as an implementation. > > When the server sends a correct header (which isn''t in all parts...) then I > do not need to set the .html parser to be XMLParser, it just recognizes the > text/xml content-type header, and parses it to a file correctly... > > I guess, I have it all working, and we''re testing happily the web service, > which is something our company does a lot of... so having Cucumber/Webrat > and Mechanize all working this way is just... outstanding, it''s fantastic, > but I don''t want to base my new suite of tests on a flawed principle! > > Thoughts welcome, or just ignore me, and I''ll sleep better knowing that > I''ve confessed my sins to the internet! > > - Lee > > _______________________________________________ > Mechanize-users mailing list > Mechanize-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mechanize-users > > > _______________________________________________ > Mechanize-users mailing list > Mechanize-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/mechanize-users >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/mechanize-users/attachments/20090626/a8dbcc7d/attachment.html>
Mat,
The new problem is that under some circumstances (read: most of them) --
when calling something like has_xpath(''/error/code'') on the
following XML, I
get an error because somewhere in the chain, something has injected some
HTML into the mix.
I documented what I thought mattered on GitHib''s Gist service -
https://gist.github.com/2817bee77fd4eec1f28b - This is the same that the
#webrat channel on freenode convinced me neede some Net:HTTP love.. though I
see what you mean, even though I think we''ll only need have_xpath()
should()
and should_not() and maybe contain() -- trying to pull have_xpath() out of
the webrat matcher is a nightmare though, sooner or later you end up down in
the depths of the code at an if *session.selenium or session.webrat* and
it''s back to the start!
Had limited success using the XPath in REXML, but that again isn''t too
intuitive!
Yours Lost,
- Lee
2009/6/26 Mat Schaffer <mat.schaffer at gmail.com>
> What''s the new plan? I often end up at mechanize just because the
base
> Net::HTTP stuff has me rolling too much of my own code. I''ll agree
that
> webrat is probably a bit much.
>
> Sent from my iPhone
>
> On Jun 26, 2009, at 6:36 AM, Lee Hambley <lee.hambley at gmail.com>
wrote:
>
> Cheers for the sanity check matt, it does treat anything with a
> content-type text/xml header is processed correctly as a File, but
text/html
> wasn''t!
> I''ve decided (with advice from the Cucumber people) that using
MEchanize
> and Webrat to test an XML webservice is mad overkill, so I''m
refactoring!
>
> - Lee
>
> 2009/6/25 Mat Schaffer < <mat.schaffer at gmail.com>mat.schaffer
at gmail.com>
>
>> Sounds cool to me. I guess the only thing that confused me a little bit
>> was the XML response to file object conversion which I though ive seen
>> mechanize already do. Other than that what you''re doing seems
sound to me.
>> Or at least not totally off the wall :-)
>>
>> -mat
>>
>> Sent from my iPhone
>>
>> On Jun 25, 2009, at 5:36 PM, Lee Hambley < <lee.hambley at
gmail.com>
>> lee.hambley at gmail.com> wrote:
>>
>> Hi,
>> This is my first post, I wanted to ask a quick question about "Bad
Form"
>> -- rather, am I doing something with Mechanise I shouldn''t be
doing?
>>
>> Here''s the long and short of it - I am using Mechanize with
Cucumber and
>> RSpec to test a *ahem* Perl XML web service.. talk about technology
soup,
>> but I have it working quite well.
>>
>> I have an example project on GitHub that actually has a contrived
Sinatra
>> application to replicate testing a 3rd party system that you can only
test
>> the interface to.
<https://github.com/leehambley/webrat-mechanize-xml-rpc/tree><https://github.com/leehambley/webrat-mechanize-xml-rpc>
>> https://github.com/leehambley/webrat-mechanize-xml-rpc
>>
>> The problem, or rather question is as such - I have, in my
application''s
>> test environment made use of PluggableParser, but overloaded it with
the
>> .default, and .html calls to parse everything as myown XMLParser class
>> (copied almost verbatim from the CSVParser example in the RDoc)
>>
>> I have effectively rendered it as not a browser, by forcing it to treat
>> anything that parses as XML as a
WWW::Mechanize::File<http://mechanize.rubyforge.org/mechanize/WWW/Mechanize/File.html>
rather
>> than a
WWW::Mechanize::Page<http://mechanize.rubyforge.org/mechanize/WWW/Mechanize/Page.html>
-
>> which I''m not sure about as an implementation.
>>
>> When the server sends a correct header (which isn''t in all
parts...) then
>> I do not need to set the .html parser to be XMLParser, it just
recognizes
>> the text/xml content-type header, and parses it to a file correctly...
>>
>> I guess, I have it all working, and we''re testing happily the
web service,
>> which is something our company does a lot of... so having
Cucumber/Webrat
>> and Mechanize all working this way is just... outstanding,
it''s fantastic,
>> but I don''t want to base my new suite of tests on a flawed
principle!
>>
>> Thoughts welcome, or just ignore me, and I''ll sleep better
knowing that
>> I''ve confessed my sins to the internet!
>>
>> - Lee
>>
>> _______________________________________________
>> Mechanize-users mailing list
>> <Mechanize-users at rubyforge.org>Mechanize-users at
rubyforge.org
>> <http://rubyforge.org/mailman/listinfo/mechanize-users>
>> http://rubyforge.org/mailman/listinfo/mechanize-users
>>
>>
>> _______________________________________________
>> Mechanize-users mailing list
>> <Mechanize-users at rubyforge.org>Mechanize-users at
rubyforge.org
>> <http://rubyforge.org/mailman/listinfo/mechanize-users>
>> http://rubyforge.org/mailman/listinfo/mechanize-users
>>
>
> _______________________________________________
> Mechanize-users mailing list
> Mechanize-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mechanize-users
>
>
> _______________________________________________
> Mechanize-users mailing list
> Mechanize-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mechanize-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/mechanize-users/attachments/20090627/0e35c821/attachment.html>