- 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>.- …
test-fixture-issues: Difference between revisions
Jump to navigation
Jump to search
(Documented test-fixture suggestions we might consider before putting into production.) |
GeorgeBrock (talk | contribs) (Possible benefits of retaining a separate assertion method for dates) |
||
| Line 21: | Line 21: | ||
<div class="entry-content discussion issues"> | <div class="entry-content discussion issues"> | ||
* <strong class="entry-title">Consider separating *Unit asserts from custom asserts</strong>. 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. | * <strong class="entry-title">Consider separating *Unit asserts from custom asserts</strong>. 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. [http://mofo.rubyforge.org/ MoFo], [http://github.com/danwrong/sumo/ 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. - [[User:GeorgeBrock|GeorgeBrock]] 16:43, 1 July 2009 (UTC) | |||
** … | ** … | ||
</div> | </div> | ||
</div> | </div> | ||
Revision as of 16:43, 1 July 2009
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.
open issue!
open issue!
- Represent history of changes using hAtom rather than hCalendar. It strikes me that hAtom would be a more appropriate format for a changelog than hCalendar.
- …
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)
- …