>> 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???
> On the other hand, testing multiple major classes like that together > is more of a module test than a unit test, isn't it? Yeah, it is. The major complication is that if the test fails it does not uniquely implicate the tested functionality. On the other hand, a slew of mock objects sounds like a maintenance nightmare, and I share Roy's concern that we would spend a lot of time debugging those. What about a compromise... Specifically, what I am thinking is as follows: - Testing the ExodusII_IO brings along a lot of MeshIO/EquationSystems/DofMap... baggage, and a test failure could be caused by an error in any of those 'subsystems' - It should be possible to recognize the functionality the unit test is using in these external classes. - So we can write more focused unit-tests for these methods which can be run in the test suite before the exodusII test, right? We should be able to unit test Mesh::read() etc... separately, and only consider the ExodusII_IO test if these other tests succeed. This seems like there is some notion of make-like dependencies which could be used here. -Ben ------------------------------------------------------------------------- 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
