New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Misfit relevance calculation is wrong #38

Closed
DaniRey opened this Issue Jun 7, 2017 · 0 comments

Comments

Projects
None yet
1 participant
@DaniRey
Member

DaniRey commented Jun 7, 2017

When trying to fit a HtmlPage or HtmlElement into a gauge, many so-called misfits will be reported during the process.

For example with the following HtmlElement

<ul>
  <li>foo</li>
  <li>bar<li>
</ul>

And the gauge
elem fits (<li>bar</li>)

The Gauge will first try to match <li>foo</li> and report a misfit. In case another candidate matches the gauge (as it is the case in our example), the misfit will be thrown away and the Gauge reports a fit.

In case no matching element is found, the Gauge will fail and report the most relevant misfits. To do so, a misfit relevance is attached to every misfit. The misfit relevance should increase the further down we go into the gauge definition.

Recent tests showed that it increases when the element is nested deeper, but doesn't if it is further down. Assume the following gauge definition

<div>
 <ul>
  <li>
   <a href="#">link</a>
  </li>
 </ul>
 <p>text</p>
<div>

If a misfit is reported when trying to fit <p>text</p> it should have a higher misfit relevance than, when reporting a misfit for <a href="#">link</a>, as we obviously managed to match everything else. Unfortunately this is currently not the case.

@DaniRey DaniRey added the bug label Jun 7, 2017

DaniRey added a commit that referenced this issue Jun 8, 2017

ScalaWebTest-38 Misfit relevance calculation is wrong
made small refactoring in Gauge to allow the misfitRelevance, when increased by nested verifications, to be propagated back and therefore making sure the misfitRelevance is calculated as expected
fixes #38

@DaniRey DaniRey closed this in #41 Jun 8, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment