Whining

WatiN is a reasonably nice tool for automating UI tests. It even has a recorder that we could probably get our BAs to understand. It seems like a great fit for having the BAs (basically 'the customer') create our acceptance tests. They click around for a bit, save the recorded test as an MSTest cs file, and send it to a developer who adds this file to our Test Project. Now, through the magic of Team Builds, we have automated acceptance tests that are owned by the business and not developers.

Except:
- WatiN basically scripts IE so it needs to open an IE window.
- VS Team Build runs as a service.
- The client's policy forces that service to run as a specific service account, not LocalSystem.
- Only a service running as LocalSystem can be allowed to interact with the desktop.

End result:
There's no way to have automated acceptance tests with WatiN as part of our CI Team Build.

Great.

There are arguments to be made about not needing acceptance tests to run at every build and maybe they could be scheduled to run nightly or something. The downside is that all the test results are now outside of all the TFS reporting. We're talking ourselves into this being ok.

What's not ok is that we were also planning to use WatiN for developers to create UI-related integration tests. Those definitely need to run as part of our CI build. Given the above restrictions, we decided to investigate the Web Test feature of MSTest. Feature-wise they seemed to be a good fit.

Except:
Web Tests are only available in the Tester edition of VSTS and all the developers have Developer edition.

How frustrating.