spam: suspected: Re: [Mono-devel-list] Graphics merge-in status
Jonathan Pryor
jonpryor at vt.edu
Thu Aug 4 20:38:49 EDT 2005
On Thu, 2005-08-04 at 04:31 -0700, Andrew Skiba wrote:
> I understand that ability to run tests without windows box is an
> advantage. I thought to commit expected results in similar way we did
> with XML tests.
Alas, I'm not familiar with the XML tests.
> By explicit "update" mechanism do you mean any particular technique?
Technique? None in particular.
For regression tests I write that rely on external files, I usually have
a "XXX-update" target. For example, if "make check" runs the regression
tests, then "check-update" would update the external resources.
For example, in my (uncommitted) lb regression test makefile, I have:
check:
# Clear out previous `check' output
-rm -Rf test/tmp
# run lb for new output, placing output into test/tmp
mono --debug lb.exe --blog-directory=`pwd`/test/in \
--prefix=test/tmp # ...
# compare new output to saved output
diff -r test/out test/tmp
check-update:
# update saved output
-rm -Rf test/out
mono --debug lb.exe --blog-directory=`pwd`/test/in \
--prefix=test/out # ...
How would you do this for System.Drawing? Probably extract all the .NET
Compare() code into Update() methods, place all the Update() methods
into a new .cs file, build that into a .exe during `make test`, and then
a `test-update` makefile target which executes the new program.
There are likely better ways, but this is a simple approach. :-)
> Also, how do you suggest to solve the .NET bug problem?
For anything that would fail under .NET, mark the test with a
[Category("NotDotNet")] attribute declaration. That way we ensure the
test keeps working under Mono but it won't be run under .NET (thus
avoiding spurious failures).
- Jon
More information about the Mono-devel-list
mailing list