Chris McMahon's Blog

Do you need to do SOAP in Ruby? First of all, install the latest version of Ruby you can stand. (I'm using this one . What the heck. I'm giving the laptop back in a few hours.) That's a fine thing, but you can't do Basic Authentication yet. You need to install a net/http that understands Basic Authentication. Ready to go? Not quite. The version of SOAP4R you have doesn't handle arguments to web services correctly. You need to install the latest SOAP4R to get your arguments handled right. Now you're ready. You might get an extraneous error message "ignored attr: {}mixed" but it probably won't affect your ability to do the job. Many many thanks to Emil Marceta for walking me through the process . Two things: 1) Perl's SOAP::Lite does this out of the box. 2) The Pickaxe dismisses SOAP pretty perfunctorily, but the beauty of SOAP is that it is (should be) very very easy for the client, using existing libraries. What would it take to put...

The closest I've seen is this post but it's still not quite the right thing. What I really want is for soap = SOAP::WSDLDriverFactory.new(WSDL_URL).createDriver to accept a user/password and do basic authentication for me, but I don't see a way to make it happen. Leave a comment if you have an idea... -Chris

Some time ago, I built an "Enterprise" disk imaging system, the equivalent of Symantec's Ghost product, from Open Source components, hosted on FreeBSD. In the process I discovered the FreeBSD ports collection , an astoundingly huge set of applications managed as part of FreeBSD itself. I used a whole raft of stuff from the ports collection as test tools in an all-Windows environment, everything from collaboration (Twiki) to network analysis (ntop). I was doing a lot of install/smoke testing, and the Frisbee disk imaging system was an important part of that work. I published an interview with Mike Hibler, Frisbee's lead developer, in the March 2005 issue of Better Software magazine . I discussed the wider issues of hosting test tools on FreeBSD in a paper for the 2005 Pacific Northwest Software Quality Conference , and now that paper has been adapted as a FreeBSD White Paper . Dru Lavigne, a noted FreeBSD evangelist and Open Source advocate not only helped me throu...

I have a new-ish laptop and I haven't bothered to install unixtools or cygwin on it. (I had a bad experience with Cygwin some time ago). I needed to grep around in the C# source code directory for stuff. Windows Search didn't do the Right Thing, and TextPad file search gave me memory errors. So I wrote a little script in Ruby to root around in the source code for stuff. Maybe it'll be useful for someone (sorry about the lack of indentation, that's left as an exercise for the reader) : require "find" Find.find("../interesting/directory") do |f| # Find.prune if f =~ /Design/ # Find.prune if f =~ /UnitTest/ if f =~ /cs/ x = File.open(f) while line = x.gets if line =~ /stuffImLookingFor/i puts f puts line end #if end #while end #if end #do

There was a recent thread on the agile-testing mail list about testing Web Services. I ended up having an interesting private conversation with the original poster, during which I said: I would immediately ask you "how are these services implemented?" Assume that your web services are implemented as pure XML-over-HTTP. I'm building a system-test framework in Ruby right now that understands how to talk to and how to listen to these XML-over-HTTP interfaces. I could just as well be using SOAP or REST, but in this case I don't have to. > > Any "Gotchas" I need to be aware of ? Special strategies / approaches / I think it boils down to two questions: the choice of tools, and the choice of approach. Almost any set of tools can work with either approach. Do you know Brian Marick's distinction between "business-facing" tests and "technology-facing" tests? The choice of approach I identified is to test with unit-like tests th...

SQE (the stickyminds people) have announced the schedule for the STAREast conference , and I'll be teaching the Scripting for Testers tutorial on May 16, almost certainly with my colleague Dave Hoover. I'm really looking forward to working with Dave. Not only is he a better programmer than me, but we share an interest in teaching, and in working with (and in being) beginners on the way to being experts. Brian Marick and Bret Pettichord started the class in 2003, and this tutorial was a major contributor to the existence of the Watir test framework, to which I've contributed a bit of work. This tutorial will be the first since 2004 not taught by Bret (and the first ever not taught by one of the two of them, as far as any of us know). It's a good class, and some great people have been a part of teaching it in the past. I'm hoping that the class will take on a life of its own from now on. Enough people have taught it, and enough people have taken it, that I t...

A typical test expects a particular set of data to exist, right? Say I have some software that accepts a chunk of XML and does a search for people in a database by last name and first name. It might accept <requestroot xmlns="http://foo"> <lastname xmlns="" > MCMAHON < /lastname> <firstname xmlns="">CHRIS</firstname> </requestroot> and it might return <responseroot xmlns="http://foo"> <user xmlns="">CHRIS MCMAHON</user> </responseroot> so I could write a test that does something like SEND <requestroot xmlns="http://foo"> <lastname xmlns="">MCMAHON</lastname> <firstname xmlns="">CHRIS</firstname> </requestroot> RECEIVE AND PARSE <responseroot xmlns="http://foo"> <user xmlns="">CHRIS MCMAHON</user> </responseroot> That is a static test, and that's how unit tests work...