On Mon, 19 Nov 2007, Derek Gaston wrote:
> So I was thinking of making up some unit tests for my ExodusII
> reader/writer... but I've run into a bit of a decision. Should we
> just store a mesh/solution in the unit testing directory (maybe in a
> ./data directory??) to read in and check to make sure everything is
> ok? Doing so isn't really a "unit test" as it tests just a bit too
> much. Ideally, we would make mock objects for everything that the
> mesh reader needs data from... and only send it that data... without
> reading anything off disk. But of course, that comes with a pretty
> hefty overhead of making all of those mock objects and getting them to
> work just like a mesh would from disk.
>
> So what do you guys think? Is it worthwhile to read a mesh from disk
> and check some things to see if it did it correctly? Or should we go
> whole hog with some mock objects???
What sorts of mock objects are you thinking of? I'm not sure how
you'll test just the reader code without a whole mock MeshBase
subclass, and after all that work it still seems like you'd have a
test that wouldn't catch some of the most likely flaws - the
interactions between the reader code and the real MeshBase
implementations. None of the read() changes I had to make to get
ParallelMesh working, for example, were really "bugs" in the I/O
classes exactly, they were just assumptions about element/node id
settings which SerialMesh always satisfied but which had to be
specifically requested of ParallelMesh.
On the other hand, testing multiple major classes like that together
is more of a module test than a unit test, isn't it? I'm really
mostly worried about how much work you'd have to do to create a new
MeshBase implementation that's good enough to pass off as the real
thing even for this one limited purpose. Maybe you could start with a
copy of SerialMesh and then pare away (or replace with {error();} all
the methods/data that the I/O code shouldn't need to use?
---
Roy
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Libmesh-devel mailing list
Libmesh-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
