This is not the greatest tagline in the world… this is just a tribute.
Here is a sneak preview of something I have been working on:
Trying to make it easier to create the Watin Models I described in my Watin Testing Pattern post.
-James
Previous post: Ben Carey announces the Big Visible Cruise
Next post: Deploying my Rails app
I am a software developer living in the Raleigh, NC area where I run Infozerk. This blog is about writing software and the business of software, as well as some .NET or Ruby on Rails from time to time. I have written a number of books and articles, the most recent being Windows Developer Power Tools.
{ 18 comments }
Duuuude! I think I just wet myself in excitement! If this work, it’ll be seriously cool and efficient for web app testing.
Why is this a good thing?
It just makes writing Watin tests alot easier and cleaner in my opinion.
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.
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
What’s wrong with tests written in C#?
>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’
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.
@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!
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
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.
I second phil’s Duuuuude comment. I’m definitely keen to see this.
We are a small web development shop who would greatly benefit using this product. Any date for your new release?
I was looking forward to this project. no more news?
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.
thank you very much, James. It should be very appreciated.
go James go
I got the latest code from SourceForge and see the Watin Model tab but no entries like that in your screen shot. Is there some trick to getting the WATIN model to work?
Comments on this entry are closed.