On Wed, Jul 27, 2011 at 3:42 PM, Dave Fugate <span dir="ltr"><<a href="mailto:dfugate@microsoft.com" target="_blank">dfugate@microsoft.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">







<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">Allen’s thoughts on this are an accurate reflection of my own as well.  On one end of the spectrum there are test files like
<a href="http://hg.ecmascript.org/tests/test262/file/1f621c6a8726/external/contributions/Google/sputniktests/tests/Conformance/15_Native_ECMA_Script_Objects/15.8_The_Math_Object/15.8.2_Function_Properties_of_the_Math_Object/15.8.2.17_sqrt/S15.8.2.17_A6.js" target="_blank">
this</a> which have ~60 individual test cases packed into them.  Long term I’d love to see these split up, it’s just kind of low priority at this point.  Maybe we could break-up the “worst offenders” in the not too distant future though…</span></p>

</div></div></blockquote><div><br></div><div>The file you link to is an excellent example for a point I was about to bring up anyway and just discussed with Dave. If this file were broken up into 64 separate source files, it would be a maintenance nightmare compared to the current one. Nevertheless, the need to break up the tests it performs into separate cases, for purposes of exclusion, running, reporting, etc, is compelling. I propose that such tests be converted into test generators. It would continue to be maintained as compact sources; but it would generate tests, with predictably mangled names, each of whom can be individually excluded, run, reported, etc.</div>

<div><br></div><div>Another example is <a href="http://codereview.appspot.com/4182070/diff/10001/tests/Generate/stdheap.json" target="_blank">http://codereview.appspot.com/4182070/diff/10001/tests/Generate/stdheap.json</a></div>
<div>which is a JSON serialization of the specified initial ES5 heap state. This is currently used by <a href="http://www.erights.org/tests/testjs/" target="_blank">http://www.erights.org/tests/testjs/</a></div>
<div>to test over 4K individual attributes. This is currently written as one monolithic test, which is why it isn't checked in anywhere. I propose that it be added to test262 as something to generate 4K separate attribute tests, each with a separate stable mangled name. These generated tests would not be considered sources.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">My best,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D">Dave<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#1F497D"><u></u> <u></u></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt">From:</span></b><span style="font-size:10.0pt"> <a href="mailto:test262-discuss-bounces@mozilla.org" target="_blank">test262-discuss-bounces@mozilla.org</a> [mailto:<a href="mailto:test262-discuss-bounces@mozilla.org" target="_blank">test262-discuss-bounces@mozilla.org</a>]
<b>On Behalf Of </b>Allen Wirfs-Brock<br>
<b>Sent:</b> Wednesday, July 27, 2011 8:02 AM<br>
<b>To:</b> Rick Waldron<br>
<b>Cc:</b> <a href="mailto:test262-discuss@mozilla.org" target="_blank">test262-discuss@mozilla.org</a><br>
<b>Subject:</b> Re: Single test per file or not?<u></u><u></u></span></p>
</div>
</div><div><div></div><div>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">My original intent in putting together the first version of test262 and its predecessor esconform @ codeplex was that each test should test only a single requirement of the specification.   Most of the original Microsoft tests were written
 that way.  However, the Sputnik tests  were not written in that manner.  When we initially integrated Sputnik we tried to mechanically breakup the multiple test files.  It didn't work so well and at the time the total number of tests over stressed the test
 driver, so we backed off from doing the conversion.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">As a matter of policy, I think we should expect new tests to be done in the single test per file manner for the reasons that David and Rick articulate.  It would be nice for someone to work on cleaning up the Sputnik tests but I guess I
 would prioritize that below creating new tests that fills in current coverage gaps.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Allen<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">On Jul 27, 2011, at 7:03 AM, Rick Waldron wrote:<u></u><u></u></p>
</div>
<p class="MsoNormal"><br>
<br>
<u></u><u></u></p>
<div>
<p class="MsoNormal">David,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Thanks for including me in this discussion. Dave Fugate and I recently had an exchange regarding granularity, that resulted in my suggesting that tests should be broken down to one aspect per test.<u></u><u></u></p>


</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">To illustrate:<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">15.1.1.3 undefined <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">The value of undefined is undefined (see 8.1). This property has the attributes { [[Writable]]: false, [[Enumerable]]: false, [[Configurable]]: false }.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">The test I had referred to is here: <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><a href="http://samples.msdn.microsoft.com/ietestcenter/Javascript/ES15.1.html" target="_blank">http://samples.msdn.microsoft.com/ietestcenter/Javascript/ES15.1.html</a><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">function testcase() {<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">  var desc = Object.getOwnPropertyDescriptor(global, 'undefined');<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">  if (desc.writable === false &&<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">      desc.enumerable === false &&<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">      desc.configurable === false) {<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">    return true;<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">  }<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">}<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Each of the property descriptor conditions should be a single stand alone test; in total there would be 4 tests covering the single unit (the unit being the whole of implementation for the Global Object value property "undefined" )<u></u><u></u></p>


</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Rick <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Wed, Jul 27, 2011 at 8:02 AM, David Bruant <<a href="mailto:david.bruant@labri.fr" target="_blank">david.bruant@labri.fr</a>> wrote:<u></u><u></u></p>
<p class="MsoNormal">[+Rick Waldron, because he had a discussion on this topic with Dave Fugate on Twitter iirc]<br>
<br>
Le 27/07/2011 13:28, Geoffrey Sneddon a écrit :<u></u><u></u></p>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">While the current test262 runner makes the assumption that there is only one test per file (see the implementation of ES5Harness.registerTest), the WebWorker-based demo MS showed off a while back allowed multiple
 tests per file. Seeming both are, as I understand it, by the same group of people, this is an interesting change.<br>
<br>
Is it intended to allow multiple tests per file, or should there be limits to one test per file (and hence only one call to ES5Harness.registerTest)?<u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal">This is an interesting topic. Granularity.<br>
I have myself been a bit annoyed once or twice by this issue. Typically, I would run the tests, see one failing and trying to see what was wrong. I can't remember which, but sometimes, the test was testing several things at once and by doing so, it was harder
 to track down where the non-conformance came from. If i recall, a good share of Sputnik imported tests tend to do this.<br>
<br>
I have not seen a rational or guidelines or rules discussing test granularity and I think it should be done. I think that for the purpose of a conformance test suite, the ultimate goal of a test should be to be able to spot instantaneously where the non-conformance
 issue comes from.<br>
There are two things that can help out:<br>
1) test description<br>
I have noticed that it wasn't always perfectly accurate. I will report bugs on that as i find time.<br>
2) test granularity<br>
<br>
You may disagree and i'd be happy to have a discussion on how tests should be designed and maybe providing a set of rules/good practices/guideline.<br>
<br>
On top of my head, I see one problem which is that some tests have dependency and rely on other parts of the spec to be conformant. So a failure in a test can be caused by what the test is testing or one of its "conformance dependency". I have no idea on how
 to help out with this issue, but i wanted to pointed out in case other had ideas.<br>
<span style="color:#888888"><br>
David</span><u></u><u></u></p>
</div>
<p class="MsoNormal"><br>
_______________________________________________<br>
test262-discuss mailing list<br>
<a href="mailto:test262-discuss@mozilla.org" target="_blank">test262-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/test262-discuss" target="_blank">https://mail.mozilla.org/listinfo/test262-discuss</a><u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div></div></div>
</div>

<br>_______________________________________________<br>
test262-discuss mailing list<br>
<a href="mailto:test262-discuss@mozilla.org" target="_blank">test262-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/test262-discuss" target="_blank">https://mail.mozilla.org/listinfo/test262-discuss</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>    Cheers,<br>    --MarkM<br>