Coveros-GitHub-Sandbox/selenified

Include Element Name in Test Report Output

mshear opened this issue · 4 comments

Currently, only the locator is provided in the test results output (in the table rows). Please output the actual Element names also, since they're already defined in our page classes and this would help with other teammates interpreting the results in the event of a failure.

Example: an element on the page DOM might not have an obvious id or name and we're forced to use something non-intuitive such as XPATH or classname that nobody would understand except the developers and test engineer. If such an element fails to be found... the test report provides the locator, which in this case would be jibberish to a layman. If the assigned Element name from our page class, as already referenced in the action (such as PageClass.carList.click(), is provided along with the locator then it will make for much quicker understanding and identification of what failed upon first glance of the test results table.

@mshear thoughts on using a picture of the image instead of just passing in another variable?
I'm curious if this would be clearer, and maybe even simpler

@mshear thoughts on using a picture of the image instead of just passing in another variable?
I'm curious if this would be clearer, and maybe even simpler

A picture of the image of what? Can you describe an example? I was thinking the OutputFile could be passed the element names (the ones we already assign) instead of just the locators? Maybe that's a spider web of source code ramifications, though.

Sorry, I meant a picture of the element, which we can get without needing any extra information. we could also allow friendly names, i'm wondering if an image of the element would be more helpful than some name

An image of it sounds cool, except that main benefit in knowing the logical element name is when there is a failure... and if there's a failure, we couldn't get an image of the element. Including an image of the elements we act upon or verify would exponentially increase the # of image files in the results directory, wouldn't it? The Target\failsafe-reports\Surefire suite directory. Maybe X image files turning into X to the nth # of image files is completely fine, though? I'm wondering if folks might balk at that, or if it's worth it when it would only be a visual aid when a given action succeeded and nothing when it fails? Maybe my suggestion isn't appealing due to either: 1) too many image files, or 2) nobody would want to send in an additional parameter for a name when defining elements.