Forum Discussion
Let us assume, the following assertions exists for a test step and you have not renamed or changed default names for the same.
When user adds the same type of assertion of Contains type, then it is some thing as below:
- Contains
- Contains 1
Here there is no issue when every thing goes fine.
Problem comes only if there is multiple failure.
Have a unique name for the assertion so that it can be identified by just overview.
For example, Contains assertion name can be:
- Is mystep's response contains value Black?
- Is mystep's response contains value MyCustomer?
Hope this is helpful.
Thanks for your suggestion, however I'm specifically asking about "message content" assertions, not "contains" assertions.
Replacing our "message content" by "contains" assertions is not an option, as we would have to create hundreds of new assertions for most of our test cases.
The problem is not to understand which assertion fails, but to know:
- which check(s) in the assertion itself failed (in the example above, 1 check amongst 160 failed but we don't know which one)
- which values were expected, and actually received
- nmrao10 years agoChampion Level 3
I just took that one as an example, and the same can be used for other assertions too.
I can understand that you have too many to rename. But you may better rename the assertions to avoid the issue posted by.
So you are free to choose what is priority/needed.In fact you can use the use the values(expected) as well in the name it self which might be appropriate at times.
- marcl10 years agoOccasional Contributor
I don't think I've made the problem clear enough. Knowing which assertion failed is easy.
The problem is that a message content assertion actually contains multiple checks at once, and I can't know which check failed.
For example if I've got a MCA called "Check that the updated values are correct", which check the following:
- foo == 1
- bar == 42
- a == 33
- b == "toto"
And I get the following data when executing my test:
- foo = 1
- bar = 2
- a = 33
- b = "toto"
In this case, the error message will say that "The assertion named 'Check that the updated values are correct' failed, failed/compared = 1/4". But I'll have no means to know that it's "bar" value which is wrong, nor which value was actually expected / received.
So no, renaming the assertion will bring nothing to the table :-/
- nmrao10 years agoChampion Level 3
Got it what you mean by.
Though that assertion has Error Message as last column in that table while defining the Message Content Assertion, that is not being show to the user in the reports. Is that expected or not, I have no clue, it can be confirmed by Smartbear team.
But if the same error message is shown probably it would have been useful to the user, in my opinion. May be the same can be bring to Smartbear attention to get that addressed.
If we take yours as an example, you have 4 checks in one assertion. It might be showing something as below if 2 of them failed.
Message Content Assertion failed : failed/compared = 2/4
Irrespective of that, you may have to rerun the test once the fixes are available, and make sure entire assertion is passed instead of partial pass.
The alternative at the moment would be, if at all the details are needed until the Smartbear revert back saying or confirming the issue and updates available, to use separate xpath assertions. Of course, it defeats the MCA assertion type.
By the way, I could try another alternative with the MCA(instead of xpath) with single property check(since multiple not working) and following are results(renamed MCA to below value) and at least the message is clear:
[Is conversion rate equal to 65?] Message Content Assertion failed : failed/compared = 1/1 [Is conversion rate equal to 70?] Message Content Assertion failed : failed/compared = 1/1
Thank you for your time for taking time to explain the problem.