<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 8, 2015 at 6:09 PM, Mark Janes <span dir="ltr"><<a href="mailto:mark.a.janes@intel.com" target="_blank">mark.a.janes@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><a href="mailto:baker.dylan.c@gmail.com">baker.dylan.c@gmail.com</a> writes:<br>
<br>
> This series updates the junit backend to allow it to properly load junit<br>
> and convert it back into piglit's internal representation, thus allowing<br>
> it to be summarized using the piglit summary tools<br>
><br>
> There is still some work that needs to be done beyond this, most of the<br>
> platform metadata isn't stored yet and restored, but I have a plan for<br>
> that. I have some other refactoring work that I think will make that<br>
> easier, and I'd like to get there before landing that.<br>
><br>
> This is enough to be able to compare junit and json results using the<br>
> console and html summaries.<br>
<br>
</span>I don't have a use case for comparing junit and json.  If anyone tried<br>
to compare json to our junit, they would see lots of differences because<br>
json does not respect the "expected-failures" filter.  That filter will<br>
also be unusable for json, because of the same test name character<br>
conversion.<br></blockquote><div><br></div><div>I think that we should make the filter work for both. I'm not sure yet what the right solution is for that, but I think it's worth making happen, I think there are a lot of reasons for it, but the main one I see is that it would eliminate distinctions between the backends.</div><div><br></div><div>I also have a series I'm working on that uses json for the intermediate atomic writes, and then having a function that just converts the TestrunResult object generated at the end of the run into the output we want (like json or junit, or nunit, or whatever else). This reduces code duplication a lot and reduces the number of code paths that aren't being tested by me a lot. This is advantageous in unify the expected failure/crash code to use the native piglit names rather than the junit names, since we could apply it before converting the tests and writing them out. That feels like the best solution to me, though it may mean some work converting our existing crash/fail lists.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> There is a caveat here, and that's patch 3. To compare json and junit we<br>
> need to be able to restore the names of the junit tests to *exactly*<br>
> what they were before, and currently we don't have a way to reverse the<br>
> '.' -> '_' conversion. My proposal is to change '.' into '___', which is<br>
> very unlikely in a real test name (though we could change it to almost<br>
> anything that would be unique). This may break some existing setup<br>
> (Mark, I think this will probably break some of our expected fail/crash<br>
> data).<br>
<br>
</span>It seems to me that it will be simpler for everyone to disallow<br>
junit/json comparisons.  I just need a way for users to visualize a<br>
dozen junit test files for disparate platforms and test suites.<br></blockquote><div><br></div><div>It might be, but I suspect that someone will try it at some point. I imagine a workflow like:</div><div>1) developer gets a report about breaking some system</div><div>2) developer makes changes, and runs subset of piglit on their system</div><div>3) developer wants to compare those changes to the original junit </div></div><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Dylan</div></div>