- 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)
- …
test-fixture-issues: Difference between revisions
Jump to navigation
Jump to search
GeorgeBrock (talk | contribs) (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: | ||
[[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><span class="type">text/html</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><span class="type">text/html</span></code>. | ||
** +1 I agree this could be simplified by taking the output type from the <code>type</code> 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 [[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 poshformat, has not been through the microformats process. test-fixture serves a purely functional purpose for microformats test-suite work.
open issue!
open issue!
- Output type could be implied from
a/@typerather than explicit?. Currently the output type is explicit in atypeattribute, 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.<span class="type">text/html</span>.- +1 I agree this could be simplified by taking the output type from the
typeattribute 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 principle), and thus we should keep it, make it optional, and fall back to thetypeattribute. Tantek 18:51, 6 July 2009 (UTC) - …
- +1 I agree this could be simplified by taking the output type from the
open issue!
open issue!
- 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)
- …