被测应用（Application Under Test）与Process.Start()的区别及Coded UI疑问

Hey there! Let's break down your questions clearly, based on my experience with Windows processes and test automation.

These two methods differ in process context, control, and how they fit into testing workflows. Here's the breakdown:

• Process Context & Ownership

  • When you launch calc.exe through your Application Under Test (AUT), the calculator becomes a child process of the AUT. It inherits the AUT's environment variables, user permissions, and runtime context. For example, if your AUT is running with admin rights, calc.exe might launch with those same rights automatically.
  • Using System.Diagnostics.Process.Start() gives you full manual control over how calc.exe starts. You can define custom settings via ProcessStartInfo: set a specific working directory, override environment variables, choose whether to use the shell, or even run it as a different user. The calculator here is a standalone process, not tied to your AUT unless you explicitly configure it to be.

• Test Isolation & Debugging

  • Launching via the AUT means the calculator's state is linked to your app's state. If the AUT has bugs (like memory leaks or invalid state), those could indirectly affect the calculator. Debugging issues would require checking both processes together.
  • Process.Start() lets you isolate calc.exe from your AUT. You can start/stop it independently, which is perfect for test cases where you need a fresh, clean calculator instance without relying on your app's behavior.

• Control & Monitoring

  • When launched through the AUT, you have limited built-in control over calc.exe. You can't easily kill it programmatically unless you traverse the process tree to find the child calculator process.
  • With Process.Start(), you get a Process object that lets you directly manage the calculator: check if it's exited with HasExited, kill it with Kill(), wait for it to close with WaitForExit(), or even read its output streams if needed.

Since you asked about Coded UI, here's what you need to know, especially tied to your scenario:

• Core Purpose: Coded UI is a Microsoft framework for end-to-end UI automation—it simulates user interactions (clicks, text input, etc.) with desktop, web, and WPF apps. It's meant to validate that your entire application workflow works as expected from a user's perspective.

• Integration with Your calc.exe Scenario

  • If your test involves a user action in the AUT that opens calc.exe (e.g., a "Launch Calculator" button), Coded UI can capture that action as part of your test script. It will interact with the AUT to trigger the launch, then can even verify interactions with the calculator itself (like checking if the display shows the right number).
  • If you need to launch calc.exe separately to test how your AUT interacts with it (e.g., sending data to the calculator), you can call System.Diagnostics.Process.Start() directly in your Coded UI test code. Just remember to clean up the process after the test to avoid leftover instances.

• Key Notes & Limitations

  • Element Identification: Coded UI uses "search properties" (like control names, IDs, or displayed text) to find UI elements. For calc.exe (a standard Windows app), it should handle identifying buttons and the display out of the box, but you might need to tweak search properties if you run into identification issues.
  • Fragility: Coded UI tests can break easily if the UI changes—even small tweaks like moving a button or changing a label can break your test. Stick to robust search properties (avoiding screen coordinates) to minimize this.
  • Deprecation Note: Important to know that Coded UI has been deprecated since Visual Studio 2019. Microsoft recommends alternatives like WinAppDriver for desktop apps, Selenium for web apps, or Playwright for cross-platform UI testing.

内容的提问来源于stack exchange，提问作者Surya sasidhar