<br><br><div class="gmail_quote">On Mon, Feb 28, 2011 at 5:26 AM, David Bruant <span dir="ltr"><<a href="mailto:bruant@enseirb-matmeca.fr">bruant@enseirb-matmeca.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">


  
    
  
  <div text="#000000" bgcolor="#ffffff">
    <font size="-1">Hi,<br>
      <br>
      Here are a couple of suggestions which, in my opinion, would help
      the community work:<br>
      - <a href="http://test262.ecmascript.org" target="_blank">test262.ecmascript.org</a><br>
      -- In the Results page, it would be useful to have a link to the
      test file in the <a href="http://hg.ecmascript.org/tests/test262/" target="_blank">http://hg.ecmascript.org/tests/test262/</a> website
      (may help to spot differences between the run test suite and the
      latest )<br>
      -- A "report a bug" link next to each bug result (or in the
      "source" popup?)</font><font size="-1"> would be useful too</font><font size="-1">. If there is such a feature in Bugzilla, the link could
      carry a preformatted bug title and pre-fill the bug report to
      point to the "Tests" component. Uniform bug titles make
      text-search easier.<br>
      <br>
      - Test searching<br>
      There are now about 10000 tests. By default, they are sorted in
      the repo by source(Sputnik |
      ietestcenter)/chapter/section/subsection/...<br>
      Even if it certainly makes sense from a test suite producer point
      of view (and directory choices has to be made anyway), it doesn't
      cover all search use cases. In order to "identify test holes" more
      efficiently as suggested under "Community Contributions" it would
      be helpful to have some tool to search for tests. For instance,
      it's currently hard to find if a test has been forgotten
      regarding:<br>
      * native prototype objects<br>
      For instance, in 15.4.2.2 is written "The [[Prototype]] internal
      property of the newly constructed object is set to the original
      Array prototype object, the one that is the initial value of
      Array.prototype". There is clearly a test to write based on that
      to make sure that Monkey-patched Array.prototype aren't used. Such
      a pattern can be found for functions (15.3.3, 15.3.4), objects
      (15.2.2.1 step 4) and certainly in other places.<br>
      * length properties<br></font></div></blockquote><div><br></div><div>Hi David,</div><div><br></div><div>At <<a href="http://codereview.appspot.com/4182070/">http://codereview.appspot.com/4182070/</a>> you'll see a draft data-driven test generation framework I'm working on, where most of the tests will be generated from a JSON description of what should be the initial state of a conforming ES5 heap (at stdheap.json). Currently the test driver at <<a href="http://www.erights.org/tests/testjs/">http://www.erights.org/tests/testjs/</a>> just does the described tests directly (try it). As Christian suggests in his comments, I'm going to rework this to generate the individual tests as separate files, so that it will integrate well into existing test frameworks.</div>
<div><br></div><div>My three biggest requests for test262:</div><div>* Be able to run offline, as sputnik and es5conform can, so testing can be used as part of a normal development cycle.</div><div>* Be able to build test262 from test262 sources in a portable manner, with depending on MS-specific C# and powershell code.</div>
<div>* Rework the test harness so that sputnik tests can convert into something similarly terse and maintainable. Right now, the sputnik->test262 conversion does not produce tests maintainable as sources.</div><div><br>
</div><div>Until these are addressed, I'll be adding further tests to sputnik and re-auto-converting to test262 periodically. Once these are addressed, we'd like to do a last conversion and then maintain the test262 sources as masters.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div text="#000000" bgcolor="#ffffff"><font size="-1">
      * Errors (make sure that code that should throw errors have a test
      for them)<br>
      * strict mode (I assume it's not going to be covered in a chapter)<br>
      * Any other cross-chapter topic you could think of.<br>
      Several different approaches could be taken to tackle that issue:<br>
      -- text-search<br>
      -- tags search<br>
      <br>
      <br>
      - Run partial test suite<br>
      Running the test suite is currently long. I'm currently reviewing
      FF4 fails. When I close my web browser, I have to re-run all
      tests. However, most of the time, I don't care about most of them.
      I just want all those that I haven't reviewed yet. I wish the
      website could offer an easy way to run for instance:<br>
      - all chapter 15.2 tests (or any chapter/section/subsection
      obviously)<br>
      - all tests found through a search (if/when some search feature
      will be available)<br>
      - all tests that has been added or changed between two test suite
      versions. If I have reviewed all tests of version x, I may not
      care about them when the x+1 version comes out.<br>
      <br>
      <br>
      - Accept user contributed tests<br>
      I have read that "Ecma’s intellectual property policies, permit
      only Ecma members to directly contribute code to the project.". I
      however think that this test suite would benefit from accepting
      contributions from the community. No one ignore how big is the
      JavaScript community on Github. No one ignore how crucial is
      JavaScript to the world as it is the most used programming
      language. I think there is a need to open up the way tests can be
      contributed.<br>
      If the E</font><font size="-1">cma’s intellectual property
      policies cannot be changed/adapted to make that happen, could ECMA
      TC-39 members find a way to accept user contributions, review them
      and then submit them to Ecma? For instance, by creating a TC-39
      github account and a test repo, people create tests, submit them
      to this repo and when there are enough of them or after a certain
      amount of time, </font><small>TC-39 members officially submit the
      tests to ECMA. There are certainly intellectual property/copyright
      issues that has to be considered, by I'm drawing some sort of main
      idea.<br>
      <br>
      I'd be happy to help out if there is anything I can do to help
      with<br>
    </small><font size="-1"><br>
      David<br>
    </font>
  </div>

<br>_______________________________________________<br>
test262-discuss mailing list<br>
<a href="mailto:test262-discuss@mozilla.org">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>