What you said is precisely the reason I asked the question.

If what you want is a good/easy way to write [unit] tests for *your* websites then WatiR/WatiN is a great way to do that.
If what you want is to create an application/service/website/whatever that POSTs some info to a webpage and then scraps off the output HTML to send to your user then the best way to do that is probably *not* via WatiN but by sending your own POST strings using http streams somehow.

to make a gross generality- you never ever want to do Automation on a server if there is another way to solve the problem. You'll run into problems with thread collisions [two threads trying to read the same file, or write the same file, etc] , memory utilization [each instance uses different memory space probably], performance problems, security problems [the thread by default would probably run under the defaul IS security context or some other low-security context. In short - avoid automation like the plague.

james c.


On Thu, Mar 20, 2008 at 6:56 PM, Jeroen van Menen <jvm@linkitprojects.nl> wrote:
Hi Adeel and James,
 
I was having the same question as James (using WatiN on the server side). If your answer is "yes" than I would wonder if WatiN is the tool to use.
 
Why you might ask? Because I think it will not scale when the load on your website grows. It would be better to handle this with http streams or a tool that wraps this (like NUnitAsp does) . This is much faster and more scalable (less overhead due to skipping the rendering of the HTML and starting and stopping IE). The downside is that if the other website you are automating uses JAVA script/AJAX, you might not be able to automate it using http streams. And of course you need to do some more coding work.
 
HTH,
Jeroen

 
2008/3/19, James Conley <james.conley@gmail.com>:
I think I might be confused but...are you creating an asp.net application that opens up a web browser [server side]?

or are you doing the typical - create a Watin test that opens up an IE instance to test your web app?

james c.