Watin Test Recorder: Watin Model Style

Here is a sneak preview of something I have been working on:

Watinrecorder

Trying to make it easier to create the Watin Models I described in my Watin Testing Pattern post.

-James

Comments

#1 Haacked on 11.28.2007 at 3:40 AM

Duuuude! I think I just wet myself in excitement! If this work, it'll be seriously cool and efficient for web app testing. :)

#2 Scott Bellware on 11.28.2007 at 5:56 AM

Why is this a good thing?

#3 JAmes avery on 11.28.2007 at 5:57 AM

It just makes writing Watin tests alot easier and cleaner in my opinion.

#4 Scott Bellware on 11.28.2007 at 6:10 AM

Folks in the thought leadership in the testing community have pointed to UI test recording as an anti-pattern.

Test recorders don't typically create test code that is factored for re-use, requiring much more code to maintain to get the coverage typcialy necessary for UI testing.

The move amongst those folks appears to be pretty steady toward application testing DSLs.

So, I guess I'll be the guy pissing in the cornflakes again, but you may be treading territory that has been scouted and written off.

#5 JAmes avery on 11.28.2007 at 6:36 AM

I agree that traditional UI test recording is a mess, that is precisely why I am working on this tool. Basically it create a model that is a simple facade to your page, making it easy to write tests that can be easily re-factored.

Did you read the pattern post I linked to? It explains the idea more than this post.

-James

#6 Simone Busoli on 11.28.2007 at 11:47 AM

What's wrong with tests written in C#?

#7 secretGeek on 11.28.2007 at 2:01 PM

>Folks in the thought leadership in the
>testing community have pointed to UI
>test recording as an anti-pattern.

hey maybe the 'appeal to authority' and 'appeal to common practice' logical fallacies are also an 'anti-pattern' ;-)



#8 Scott Bellware on 11.28.2007 at 4:33 PM

I id read the test pattern post. I think the pattern represents something better than straight, linear, control-oriented test scripts, but it's an intermediary step toward application DSL-based testing that will yield better DRY results and more grokable code.

Once you harvest a *good* DSL for your app, you *might* find the the need for a recorder has mitigated itself.

#9 Scott Bellware on 11.28.2007 at 4:42 PM

@secretGeek,

Yeah, that's usually the official party line for The Society for the Preservation of Software Technology Anachronism.

Not sure if you're pointing out for effect, if you're a card-carrying member. I'll play along though...

Yep. I'm such a good programmer, I don't see how I could possibly not be naturally endowed with all the knowledge relevant to contemporary software testing practice. Sheesh. God bless yesterday. if it weren't for what I learned yesterday, I might be expected to continue to make an effort to learn again today... let alone tomorrow! :)

#10 JAmes avery on 11.28.2007 at 4:58 PM

Scott,
I see where you are going with that (the DSLs and such), and it is something I will look into more. But, I also think there is room for this tool as well. I have 100s of pages to cover and no business users available to write tests, this will help me do that so I can get on the road of refactoring this boat. It might also work better for people like Phil who are working on open source projects with no real business users to speak of (and a large legacy code base as well)

If anyone else is interested in the DSL approach here is a good intro:

http://codebetter.com/blogs/jeremy.miller/archive/2006/07/15/147400.aspx


-James

#11 Scott Bellware on 11.28.2007 at 7:21 PM

Just to be clear, I'm talking about core DSL for testers, not customers. Jeremy is talking about customer DSL through FitNesse.

This point also goes to the assumption that led to the creation of Watin by .NET developers: that C# and Ruby are equals among languages for testing.

Part of the reason why Watir is powerful, is that Ruby is a great language for evolving a DSL from an API.

This is a point that C# developers miss because there is no notion of a next level of abstraction in C# above an API, and the process of abstraction for C# developers is prematurely terminated at the API.

This shortcomming of exploration and understanding on the part of .NET developers into a new knowledge realm is a big reason why Watin exists in the first place.

If you're a .NET developer without a purview into *why* leading testers are using Ruby, and without a purview into Ruby capabilities that reach over and above those of C#, you might just assume that Watir's power rests merely in its ability to automate a browser, and therefore there's no reason why a C# clone shouldn't be created so that C# programmers wanting a piece of the browser automation game can continue with C#.

Ruby and C# aren't languages of equivalent capability; Watir and Watin are tools that reflect the capabilities of the underlying environment; .NET developers might have learned something valuable from Watir if they had believed that they had something to learn before creating Watin.

Folks, even the testers are out-pacing us .NET developers on matters of plain old programming practice.

#12 Joshua McKinney on 11.30.2007 at 1:50 AM

I second phil's Duuuuude comment. I'm definitely keen to see this.

#13 Ken Draper on 1.25.2008 at 8:18 PM

We are a small web development shop who would greatly benefit using this product. Any date for your new release?

#14 stefano on 2.19.2008 at 7:49 AM

I was looking forward to this project. no more news?

#15 James Avery on 2.19.2008 at 3:50 PM

I got pulled in other directions, but the work is done and hopefully in the next week or two I am going to integrate it into the main watin code.

#16 stefano on 2.27.2008 at 1:42 PM

thank you very much, James. It should be very appreciated.

#17 jfk on 3.18.2008 at 7:22 PM

go James go :-)

Leave a Comment