|It might be time to tell the my idéa.
B is a WPF-application my company has. We don't have any unit test for the GUI of B. We want that.
So I thought if:
* B is a WPF-project in our Visual Studio solution.
* A is a unit test project in the same solution.
* A has some "code/package/NuGet" to start, terminate B and gain access of all public controls in B.
* In A we write the unit tests that use the "code/package/NuGet" to access the controls in B to do our unit tests.
For instance if I want to test a button's click event in B:
1) In A: Run a specific test case.
2) In A: Start B.
3) In A: Someway gain access of all public controls of B.
4) In A: Put a text in a TextBox located in B.
5) In A: Trigger the click event of a Button located in B.
6) In B: The Button's click event puts the TextBox's text in a TextBlock.
7) In A: Read the Text from the TextBlock inside of B.
8) In A: Verify the text and pass or fail the test.
9) In A: Terminate B.
I have looked at Appium with the WinAppDriver solution. That works, but it requires the WinAppDriver application running in the background to handle all communications between A and B. I don't want a third party or be forced to write any IPC in B.
Unit test should be easy to write and run. If each develop must install the WinAppDriver to run tests, it's just tedious.
However, I like the way that WinAppDriver use the
AutomationProperties.AutomationId and other properties on controls to allow "A" to access it "B". I would like a similar solution.
How should I do to instantiate B in A?
If that give me access to all public controls, that will be fine!