Re: Fixture.error() as well as exception()?

--===============0049857384698013263==
Content-Type: multipart/alternative; boundary=Apple-Mail-6-380841646


--Apple-Mail-6-380841646
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=ISO-8859-1;
	format=flowed


On Thursday, September 25, 2003, at 06:34  AM, Rick Mugridge wrote:

> I see that there's an extra colouring mechanism built into RowFixture=20=

> which is just what I'm after. It could be pulled up into Fixture for=20=

> general use.=A0 It's associated with the mark() method, which colours=20=

> red. I'm happy for it to be counted as a wrong.

There are several versions of the mark() method that depend on several=20=

representations that are specific to RowFixture. They rely on a more=20
primitive  version of wrong() than is normally used since they have a=20
different sense of wrong that is the norm. They provide a good example=20=

of how the Fixture class provides both basic functionality and=20
convenience for the normal case.

These are the primitive coloring methods:

right(Parse cell)
wrong(Parse cell)
exception(Parse cell) **
ignore(Parse cell)

And these are the convenience calls that adds frequently available=20
additional information in the annotation of the cell:

wrong(Parse cell, String actual)
exception(Parse cell, Throwable exception)

I can imagine fixtures providing even more exotic annotation and have=20
done so in a few cases myself. In one case I found it fruitful to=20
include trace information that lead up to failures as part of the=20
annotation in the failing cell. The decision to do so seems naturally=20
that of the fixture writer so I am in favor of leaving the design of=20
annotations a fixture responsibility.

(At times, Jim Little convinces me that annotations are the=20
responsibility of Parse, though I believe I have undone the convincing=20=

in the previous paragraph.)

The careful reader will notice that I have misrepresented the current=20
state of Fit (at least the Java) when I say that exception(Parse cell)=20=

is available as a primitive coloring method in Fixture (see ** case=20
above).

Perhaps it's omission is what started this thread. I would be happy to=20=

add in the name of functional regularity. I still think it a bad idea=20
to field exceptions and not pass them on to the testers.


--
Ward Cunningham
503-245-5633 v	mailto:[email protected]
503-246-5587 f	http://c2.com

--Apple-Mail-6-380841646
Content-Transfer-Encoding: quoted-printable
Content-Type: text/enriched;
	charset=ISO-8859-1



On Thursday, September 25, 2003, at 06:34  AM, Rick Mugridge wrote:


<excerpt><color><param>0000,0000,0000</param>I see that there's an
extra colouring mechanism built into RowFixture which is just what I'm
after. It could be pulled up into Fixture for general use.=A0 It's
associated with the mark() method, which colours red. I'm happy for it
to be counted as a wrong.

</color></excerpt>

There are several versions of the mark() method that depend on several
representations that are specific to RowFixture. They rely on a more
primitive  version of wrong() than is normally used since they have a
different sense of wrong that is the norm. They provide a good example
of how the Fixture class provides both basic functionality and
convenience for the normal case.


These are the primitive coloring methods:


right(Parse cell)

wrong(Parse cell)

exception(Parse cell) **

ignore(Parse cell)


And these are the convenience calls that adds frequently available
additional information in the annotation of the cell:


wrong(Parse cell, String actual)

exception(Parse cell, Throwable exception)=20


I can imagine fixtures providing even more exotic annotation and have
done so in a few cases myself. In one case I found it fruitful to
include trace information that lead up to failures as part of the
annotation in the failing cell. The decision to do so seems naturally
that of the fixture writer so I am in favor of leaving the design of
annotations a fixture responsibility.


(At times, Jim Little convinces me that annotations are the
responsibility of Parse, though I believe I have undone the convincing
in the previous paragraph.)


The careful reader will notice that I have misrepresented the current
state of Fit (at least the Java) when I say that exception(Parse cell)
is available as a primitive coloring method in Fixture (see ** case
above).


Perhaps it's omission is what started this thread. I would be happy to
add in the name of functional regularity. I still think it a bad idea
to field exceptions and not pass them on to the testers.=20



--

Ward Cunningham

503-245-5633 v	mailto:[email protected]

503-246-5587 f	http://c2.com


--Apple-Mail-6-380841646--



--===============0049857384698013263==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Fit-dev mailing list
[email protected]
http://lists.freepan.org/mailman/listinfo.cgi/fit-dev

--===============0049857384698013263==--