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

This is a multi-part message in MIME format.
--===============37859848914376215==
Content-Type: multipart/alternative;
 boundary="------------040803050109020801090806"

This is a multi-part message in MIME format.
--------------040803050109020801090806
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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.  It's associated with the mark() method, which colours red. 
I'm happy for it to be counted as a wrong.

[However, if it is given a different colour and is counted separately, I 
suggest calling it fault(). That's so it will fit nicely into my 
fitBookFixtureFixture, which I use for test-driving the development of 
my own fixtures. I've almost finished "defining" the standard fixtures 
with it (and itself) and will release it all in a day or so. I'll 
announce it here].

There are two cases with the use of fault(). The one I was thinking of 
is where the fixture itself generates a fault(), such as with RowFixture 
(eg, "missing"). It would be easy to have a special Exception subclass 
(eg, FixtureFaultException) that's picked up by fixtures and its String 
argument passed to fault().

Yes, 'error' is a special cell value in ColumnFixture, which is right() 
if any exception is thrown but is otherwise wrong().  ColumnFixture also 
has the special cell value ' ' for fields and method calls, whicb 
reports the value. Are there any other special cell values?

I usually code error handling into my specialised fixtures, but don't 
often check for the specific exception type. It would be more precise to 
do so, but it becomes language-dependent. That is, unless we have 
cross-language agreement for certain exception names (which could be 
handled indirectly in languages without exceptions).

I suspect it's best to handle it in the code of the fixture itself, so 
that the table is not polluted with such (customer-irrelevant) details.

Cheers, Rick

[email protected] wrote:

----- Original Message ----- 
From: "Rick Mugridge" <[email protected]>
To: "FIT Developers" <[email protected]>
Sent: Tuesday, September 23, 2003 6:19 AM
Subject: [Fit-dev] Fixture.error() as well as exception()?



>I have code in several specialised fixture that has to throw an 
>exception (and thus call Fixture.exception()) because an argument is 
>invalid or whatever. The exception stackdump is irrelevant and clutters 
>up the result when all I want is to provide a simple error message. Eg, 
>"Unknown state".
>
>Has anyone else struck this?
>  
>

There are a number of examples in the sample programs
where a simple error message would be preferable to a
stack dump. I've never been comfortable with providing 
a stack dump where the error is something that could
reasonably be expected. I'd prefer to reserve stack dumps
for something that the developer has to fix,
rather than things like invalid input data that the test
writer has to fix.


>So I suggest adding a new 'colouring' method to Fixture, such as 
>error(). It takes a cell and a String and acts like wrong(), except that 
>the top half is just whatever was in the cell before and the bottom half 
>is just the error message.
>
>That is, something like
>
>    public void error(Parse cell, String message) {
>        wrong(cell);
>        cell.addToBody("<hr>" + escape(message));
>    }
>  
>

It needs to be a different color than a simple wrong() though.
Otherwise, you've got the possibility of confusion with string
output.

The other question I have is: how does Fixture know that
the exception should be an error message rather than a
stack dump? I could undoubtedly manage this in the Python
version with a special exception class. Presumably the
Java version would be the same?

A related question is: how do you test error handling?
Right now, I believe "error" is a special word, but it does
not have the capability of checking for a specific error.
I think the only way to do it right now is to use a second
column (with it's own method, of course) to return the
error message. This needs to be clarified, I think, into a
standard (or at least recommended and supported) way 
of doing it.

John Roth


>Cheers, Rick
>  
>

--------------040803050109020801090806
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
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.&nbsp; It's associated with the mark()
method, which colours red. I'm happy for it to be counted as a wrong. <br>
<br>
[However, if it is given a different colour and is counted separately,
I suggest calling it fault(). That's so it will fit nicely into my
fitBookFixtureFixture, which I use for test-driving the development of
my own fixtures. I've almost finished "defining" the standard fixtures
with it (and itself) and will release it all in a day or so. I'll
announce it here].<br>
<br>
There are two cases with the use of fault(). The one I was thinking of
is where the fixture itself generates a fault(), such as with
RowFixture (eg, "missing"). It would be easy to have a special
Exception subclass (eg, FixtureFaultException) that's picked up by
fixtures and its String argument passed to fault().<br>
<br>
Yes, 'error' is a special cell value in ColumnFixture, which is right()
if any exception is thrown but is otherwise wrong().&nbsp; ColumnFixture
also has the special
cell value ' ' for fields and method calls, whicb reports the value.
Are there any other special
cell values?<br>
<br>
I usually code error handling into my specialised fixtures, but don't
often check for the specific exception type. It would be more precise
to do so, but it becomes language-dependent. That is, unless we have
cross-language agreement for certain exception names (which could be
handled indirectly in languages without exceptions). <br>
<br>
I suspect it's
best to handle it in the code of the fixture itself, so that the
table is not polluted with such (customer-irrelevant) details.<br>
<br>
Cheers, Rick<br>
<br>
<a class="moz-txt-link-abbreviated" href="mailto:[email protected]">[email protected]</a> wrote:<br>
<pre wrap="">----- Original Message ----- 
From: "Rick Mugridge" <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]">&lt;[email protected]&gt;</a>
To: "FIT Developers" <a class="moz-txt-link-rfc2396E" href="mailto:[email protected]">&lt;[email protected]&gt;</a>
Sent: Tuesday, September 23, 2003 6:19 AM
Subject: [Fit-dev] Fixture.error() as well as exception()?


</pre>
<blockquote type="cite">
  <pre wrap="">I have code in several specialised fixture that has to throw an 
exception (and thus call Fixture.exception()) because an argument is 
invalid or whatever. The exception stackdump is irrelevant and clutters 
up the result when all I want is to provide a simple error message. Eg, 
"Unknown state".

Has anyone else struck this?
  </pre>
</blockquote>
<pre wrap=""><!---->
There are a number of examples in the sample programs
where a simple error message would be preferable to a
stack dump. I've never been comfortable with providing 
a stack dump where the error is something that could
reasonably be expected. I'd prefer to reserve stack dumps
for something that the developer has to fix,
rather than things like invalid input data that the test
writer has to fix.

</pre>
<blockquote type="cite">
  <pre wrap="">So I suggest adding a new 'colouring' method to Fixture, such as 
error(). It takes a cell and a String and acts like wrong(), except that 
the top half is just whatever was in the cell before and the bottom half 
is just the error message.

That is, something like

    public void error(Parse cell, String message) {
        wrong(cell);
        cell.addToBody("&lt;hr&gt;" + escape(message));
    }
  </pre>
</blockquote>
<pre wrap=""><!---->
It needs to be a different color than a simple wrong() though.
Otherwise, you've got the possibility of confusion with string
output.

The other question I have is: how does Fixture know that
the exception should be an error message rather than a
stack dump? I could undoubtedly manage this in the Python
version with a special exception class. Presumably the
Java version would be the same?

A related question is: how do you test error handling?
Right now, I believe "error" is a special word, but it does
not have the capability of checking for a specific error.
I think the only way to do it right now is to use a second
column (with it's own method, of course) to return the
error message. This needs to be clarified, I think, into a
standard (or at least recommended and supported) way 
of doing it.

John Roth

</pre>
<blockquote type="cite">
  <pre wrap="">Cheers, Rick
  </pre>
</blockquote>
</body>
</html>

--------------040803050109020801090806--



--===============37859848914376215==
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

--===============37859848914376215==--