Point 1 : Automated Testing using the Visual Studio Coded GUI
For starters ensure you're running the latest Visual Studio (Including all the patches). Don't try and pull this off with VS2010 or VS2012. Also you will need VS2013 Premium, I have not yet looked at VS2015.
Here it's pretty simple to record the controls to your UI Map. As for the recordings I wouldn't bother recording them. Only use the recorder for control identification and then write the actual tests by hand.
Your success is heavily dependent on what controls are in your WinApp. For example are you using Telerik or DevExpress or Standard .Net Winforms? Perhaps even a C++ WIn32 App? This is because controls like DevExpress do not use MSAA but expose their own technology type with better properties and methods exposed for testing. WIth MSAA it depends heavily how the developer implemented accessibility to expose the correct properties and methods. So if they haven't done any exposure on a C++ Win32 App, then it's unlikely any nested composite controls will have enough exposure for you to easily test the application.
Point 2: Setting up Test Settings/Agents to run virtually on a VM to run the tests (like being logged in, but not)
Your best route here is to use a full blown labs environment. Then execute your tests using MTM (Microsoft Test Manager).
So the basic topography is like this:
- You'll need a TFS Build Server (Consisting of a build controller and an agent)
- A Test Controller
- A Test Agent
Register the build environment with TFS, then in Visual Studio, once you've checked your code into TFS, Queue a new build.
Your Test controller should be registered with TFS, but your test agents DO NOT get registered to the Test controller. Instead they should be setup in Labs environment (part of the MTM GUI).
This way once you've assigned a build to a project (Using MTM -> project -> properties), and setup your agents (and installed TFS agent inside an agent), and created test environments (MTM), you can right click and run tests using MTM.
However there are a few pitfalls, you can in theory get the tests to run with autologin, but this is ridiculously unreliable inside a VM. Unless you have a physical test machine, every time you run tests using MTM, it's best to open and minimize the lab environment.
Point 3 : Getting help with element examination (like differentiating between some developer using 'toolStrip1' as the ID in three different places on the GUI)
This will not be a problem if you use the recorder to identify controls. This is because CodedUI uses a lookup chain and search patterns to identify controls. It does indeed check the parent -> child relationships.
