编码的UI-尽管有错误仍继续测试运行 [英] Coded UI-Continue the test run in spite of error

问题描述

我的测试用例包含10个以上的断言。假设第三个断言中存在问题（即）我用于该第三个断言的Ui或对象未被该工具识别。 找不到控件，同一测试用例的其余部分未完成。

My test case contains more than 10 assertions.Assume there is a problem in the third assertion(ie.) the Ui or object I have used for the third assertion is not recognized by the tool.Now the entire test case fails saying "Unable to find the control",the rest part of the same test case is not done.

完全运行测试用例是否可行（继续所有其他的断言，尽管第三个断言有错误，但
假设未识别的控件仅用于第三个断言。）

Is it feasible to run the test case fully( to continue with all the other assertions, in spite of error in the third assertion,assuming the unrecognized control is used only for the third assertion.)

请注意
Amsa

regards Amsa

推荐答案

唯一的方法是混乱的。编码的UI与断言一起使用，这些解释应解释为 [something]在此处应为真，否则，请立即停止测试失败。

The only way is messy. Coded UI works with assertions which are intended to be interpreted as "[something] should be true here and, if not, stop immediately failing the test".

有多种方法可以避免立即停止部分，但是大多数都归结为样式代码：

There are various approaches to avoiding the "stop immediately" part, but most boil down to code of the style:

try {
    ... an assertion ...
}
catch (...)
{
    ... remember and/or report the detail of the failed assertion ...
}

try {
    ... another assertion ...
}
catch (...)
{
    ... remember and/or report the detail of this failed assertion ...
}

if ( any assertion above was caught OR anything was remembered )
{
    // Something failed.
    report the remembered items
    Assert.Fail(... some message...);
}

try ... catch ... { } 可以根据需要重复。 catch 子句可能很难编写，除非您仅捕获最一般的异常。执行报告和记忆的代码可能会引发异常。在 try ... 语句之间，可能会调用一些非断言方法，这些方法可能会失败，因此也需要将它们包装在 try中。 .. 语句。整个测试非常麻烦，并且由于以后未处理的异常，有可能被发现并记住但没有报告的错误。

The try...catch...{} can be repeated as necessary. The catch clauses can be difficult to write unless you only catch the most general exceptions. The code that does the reporting and remembering may throw exceptions. Between the try... statements there may be calls of non-assertion methods that may fail, so these would also need to be wrapped in try... statements. The whole test gets very cumbersome and risks having faults that are detected and remembered but not reported because of a later unhandled exception.

这篇关于编码的UI-尽管有错误仍继续测试运行的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！