- 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
Jump to navigation
Jump to search
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)
- …