In the last implementation of the WindowSearcher I was to lazy about testing it, I got reported that child windows were never be found. And main window too if no timeout was set explicit.
I have fixed both in the current version.
- The Default timeout of the WindowFinder.Search is changed from 0 to 10 seconds like in the ApplicationFactory
- The WindowSearcher internally is working different than before, now it doesn't matter if the window is a top or a child window, it gets found in few nano seconds
(The usage has not been changed)
Facts:
Library: DW.CodedUI
Tool: AutomationElementFinder
Version: 13.5.14.0
Date: 2013-5-14 17:55
I was not really happy how the window handling was working in the DW.CodedUI. It was slow (if the window was not available for example) and unsafe.
Because of that I have renewed the handling, the old functionality is marked as obsolete and will be removed in the upcoming versions.
What is changed in detail:
- Already marked obsolete objects are removed
- Obsolete overload in the ColorDetector is removed
- A window is represented by a BasicWindow with some basic functionality like Minimize, Maximize, WindowState and so on
- WindowFocus now has obsolete methods for the TestableApplication and TestableWindow and gets a new method for the BasicWindow
- Added WindowFinder to search for windows on a very generic and fast way
- TestableApplication and TestableWindow is marked as obsolete
- Shutdown object has overload to close a BasicWindow, the other methods with the WpfWindow and TestableApplication are marked as obsolete
- ApplicationFactory has a new method to launch an application on a easier way and returns a BasicWindow, the old is marked as obsolete
- In the AutomationElementFinder the sibling elements are separated by a horizontal line in the left tree
To launch an application now just do like this:
[CodedUITest]
public class AnyWindowTests
{
private BasicWindow _target;
[TestInitialize]
public void Setup()
{
_target = ApplicationFactory.Launch(@"..\..\..\Anypath\MyApplication.exe");
}
[TestCleanup]
public void Teardown()
{
_target.Unsafe.Close();
}
[TestMethod]
public void Method_TestCondition_ExpectedResult()
{
var anyButton = BasicElementFinder.FindChildByAutomationId<BasicButton>(_target, "AnyButton");
MouseEx.Click(anyButton);
//Assert
}
}
To search for an already open window call stuff like this:
[TestMethod]
public void Method_TestCondition_ExpectedResult()
{
var window = WindowFinder.Search("title", WindowSearchCondition.TitleContains, StringComparison.OrdinalIgnoreCase);
Assert.IsNotNull(window);
WindowFocus.BringOnTop(window);
// Do any other stuff with the window
window.Unsafe.Close();
}
See the documentation for details.
Facts:
Library: DW.CodedUI
Tool: AutomationElementFinder
Version: 13.5.7.0
Date: 2013-5-7 22:32
Just a small update.
With the ApplicationFactory it is possible to launch the application for automated UI testing. This works good but there was one problem, the working directory was not set. If the application does not handle this it was possible that anything has failed because of missing files and so on.
To prevent such problems the ApplicationFactory sets the working directory to the directory the executable to launch is located.
Facts:
Library: DW.CodedUI
Tool: AutomationElementFinder
Version: 13.4.5.0
Date: 2013-4-5 17:55
Until now the ApplicationFactory and the TestableWindow was able to find a WPF Window by the title only if the whole title has been matched.
But now it is possible to say if the title has to contain the given one or matches exactly.
For details see the Launch parameters in the ApplicationFactory or the constructor overloads in the TestableWindow.
Facts:
Library: DW.CodedUI
Tool: AutomationElementFinder
Version: 13.2.25.0
Date: 2013-2-25 18:46
