Take the 2-minute tour ×

I'm using CodedUI test for apps developed in sharepoint. The problem is it wont work across different environments. So I have to re-record the test for each environment which is cumbersome and prone to error.

With a little investigation, it turns out that the generated clientId for the server controls in a webpart a different on each environment (even if everything in the page is exactly the same - masterpage, pagelayout, webparts).

To work around this problem (almost) I thought of editing the SearchPropertyExpressions to just use the last segment of the clientID with a "contains" operator. This works well if you manually edit the generated code in designer.cs.

My question is, is there any easy and elegant way to automate this?

Here's what I've tried so far: I replaced the indexer setter PropertyExpressionCollection class with my own function. I use this function to check the values thats being set and change the ones with the string "ctl" and replace it with the last segment of the string (ex replace "ctl0123_textbox1" with "textbox1") and finally use a contains operator. It works fine. but it is indiscriminate in filtering out input - it doesnt care whether its a Filter or Search and it doesn't even know what type of control it belongs to. This method is hacky indeed.

share|improve this question
I never thought about hacking the CLR nice idea. –  stoj Dec 9 '11 at 19:06

1 Answer 1

up vote 2 down vote accepted

We face exactly the same issue now (must support 20 customized versions of our app). General solution we came to:

1) abstract UI interactions from business logic (we have custom fabric for UITestControls which deserializes them from XML file)

2) for each client tweak UI interaction logic as it needed and branch it exactly the same way developers do to tweak the application

3) so, for every branch of the application ('different environment') we have same logic but different UI layer

4) we may now give our tests the XML UI notation file intended for use on this environment and be happy

This solution is hard, needs some complicated code but gives us needed flexibility. And, well, we don't record our test, we create them from scratch, so the code is much cleaner and more maintainable.

Hope this helps. I may provide more detailed info if you need.

share|improve this answer

Your Answer


