Difference between revisions of "test-fixture-issues"

From Microformats Wiki
Jump to navigation Jump to search
(Possible benefits of retaining a separate assertion method for dates)
(agree with a couple of issues, add a new issue about output should be permissible inline in the test case, edit page intro a bit)
Line 1: Line 1:
Issues against test-fixture. Note that this poshformat has not been through the microformats process and serves a funcational purpose for the [[test-suite]] work.
+
[[test-fixture]] issues. Note that test-fixture is a [[poshformat]], has not been through the microformats [[process]].  test-fixture serves a purely functional purpose for microformats [[test-suite]] work.
 +
 
 +
<div class="hentry">
 +
{{OpenIssue}} <span class="entry-summary author vcard"><span class="published">2009-07-06</span> raised by <span class="fn">[[User:Tantek|Tantek Çelik]]</span></span>
 +
<div class="entry-content discussion issues">
 +
* <strong class="entry-title">Output should be specifiable inline, rather than having to be external</strong>. Currently the output appears to require linking to an external file, while it can be much more convenient as a test author to specify the output in the test case file itself. In fact, "output" on anything other than a hyperlink should mean that the output is inline in the test case page, rather than in a separate resource. For example: [[value-dt-test-YYYY-MM-DD--HH-MM]]. [[User:Tantek|Tantek]] 18:51, 6 July 2009 (UTC)
 +
** …
 +
</div>
 +
</div>
  
 
<div class="hentry">
 
<div class="hentry">
Line 5: Line 13:
 
<div class="entry-content discussion issues">
 
<div class="entry-content discussion issues">
 
* <strong class="entry-title">Output type could be implied from <code>a/@type</code> rather than explicit?</strong>. Currently the output type is explicit in a <code>type</code> attribute, but either the output could just be taken from the anchor, or if it is duplicated visibly, perhaps it should match the MIME type rather than using strings? e.g. <code>&ltspan class="type">text/html&lt;/span></code>.
 
* <strong class="entry-title">Output type could be implied from <code>a/@type</code> rather than explicit?</strong>. Currently the output type is explicit in a <code>type</code> attribute, but either the output could just be taken from the anchor, or if it is duplicated visibly, perhaps it should match the MIME type rather than using strings? e.g. <code>&ltspan class="type">text/html&lt;/span></code>.
 +
** +1 I agree this could be simplified by taking the output type from the <code>type</code> attribute of an &lt;a href class="output"&gt; rather than making it explicit. However, I think the explicit visible one is a good one (per the visibility [[principle]]), and thus we should keep it, make it optional, and fall back to the <code>type</code> attribute. [[User:Tantek|Tantek]] 18:51, 6 July 2009 (UTC)
 
** …
 
** …
 
</div>
 
</div>
Line 13: Line 22:
 
<div class="entry-content discussion issues">
 
<div class="entry-content discussion issues">
 
* <strong class="entry-title">Represent history of changes using hAtom rather than hCalendar</strong>. It strikes me that [[hAtom]] would be a more appropriate format for a changelog than hCalendar.
 
* <strong class="entry-title">Represent history of changes using hAtom rather than hCalendar</strong>. It strikes me that [[hAtom]] would be a more appropriate format for a changelog than hCalendar.
 +
** +1 agreed. Let's use hAtom for this, not hCalendar. [[User:Tantek|Tantek]] 18:51, 6 July 2009 (UTC)
 
** …
 
** …
 
</div>
 
</div>

Revision as of 18:51, 6 July 2009

Test Fixture issues. Note that test-fixture is a poshformats, has not been through the microformats The microformats process. test-fixture serves a purely functional purpose for microformats microformats test suites work.

open issue! 2009-07-06 raised by Tantek Çelik

  • Output should be specifiable inline, rather than having to be external. Currently the output appears to require linking to an external file, while it can be much more convenient as a test author to specify the output in the test case file itself. In fact, "output" on anything other than a hyperlink should mean that the output is inline in the test case page, rather than in a separate resource. For example: value-dt-test-YYYY-MM-DD--HH-MM. Tantek 18:51, 6 July 2009 (UTC)

open issue! 2009-06-26 raised by BenWard

  • Output type could be implied from a/@type rather than explicit?. Currently the output type is explicit in a type attribute, but either the output could just be taken from the anchor, or if it is duplicated visibly, perhaps it should match the MIME type rather than using strings? e.g. &ltspan class="type">text/html</span>.
    • +1 I agree this could be simplified by taking the output type from the type attribute of an <a href class="output"> rather than making it explicit. However, I think the explicit visible one is a good one (per the visibility principles), and thus we should keep it, make it optional, and fall back to the type attribute. Tantek 18:51, 6 July 2009 (UTC)

open issue! 2009-06-26 raised by BenWard

  • Represent history of changes using hAtom rather than hCalendar. It strikes me that hAtom 0.1 would be a more appropriate format for a changelog than hCalendar.
    • +1 agreed. Let's use hAtom for this, not hCalendar. Tantek 18:51, 6 July 2009 (UTC)

open issue! 2009-06-26 raised by BenWard

  • Consider separating *Unit asserts from custom asserts. Although the normalisation of Geo and Dates is a very useful enhancement, they may not be essential (since ISO dates can be compared somewhat reliably as strings, and co-ordinates compared to the same precision as they appear in the source). This seems desirable for simple conversion into something like JUnit, without being dependent on additional functions.
    • Some parsers discard the ISO string in favor of another date representation (e.g. MoFo, Sumo). When testing these parsers, equality assertions for dates would require some additional logic to compare the parsed value to the asserted value. For parsers that output dates as a generic data type (e.g. as an integer containing a UNIX timestamp) detecting when to apply this date-specific logic would be non-trivial and could require knowledge of which µf fields should contain dates, undermining the design goal of self contained tests. Keeping a separate equality assertion method for dates could therefore reduce complexity overall. - GeorgeBrock 16:43, 1 July 2009 (UTC)