Comments on: Parent-Child Unit Tests http://www.jeffongames.com/2008/04/parent-child-unit-tests/ This is Jeff. This is Jeff On Games. Tue, 31 Jan 2012 21:30:53 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Jeff http://www.jeffongames.com/2008/04/parent-child-unit-tests/comment-page-1/#comment-20564 Jeff Wed, 16 Apr 2008 17:20:13 +0000 http://www.jeffongames.com/2008/04/parent-child-unit-tests/#comment-20564 The setup / teardown are actually extremely slow, because they all involve generating code. It's not slow, but it's not fast either, so generating before each test isn't an option if I want the tests to finish in a reasonable amount of time. As for using mock objects, unfortunately that's not an option because what I'm testing is the generated syntax against the actual database. A mock object can't actually tell me if the database syntax is *actually* correct. These are technically integration or functional tests, but they're using the same unit test library anyway. The setup / teardown are actually extremely slow, because they all involve generating code. It’s not slow, but it’s not fast either, so generating before each test isn’t an option if I want the tests to finish in a reasonable amount of time.

As for using mock objects, unfortunately that’s not an option because what I’m testing is the generated syntax against the actual database. A mock object can’t actually tell me if the database syntax is *actually* correct. These are technically integration or functional tests, but they’re using the same unit test library anyway.

]]> By: David Ludwig http://www.jeffongames.com/2008/04/parent-child-unit-tests/comment-page-1/#comment-20456 David Ludwig Sun, 13 Apr 2008 18:11:33 +0000 http://www.jeffongames.com/2008/04/parent-child-unit-tests/#comment-20456 I have not yet run into a case whereby I needed to have data be shared among several unit tests. If I was doing work with large databases, I might want to do this, however most of the unit tests I've needed to write ran fairly quickly. Just how slow would it be to do a set up and tear down for each test case you are working with? Could some of those cases use mocks instead of a real DB, or is that infeasible? Regarding hierarchical fixtures, I've used such in a C++ library, UnitTest++. With this library, fixtures were still set up as classes, however the set up and tear down code would be placed in the class' constructor and destructor, as opposed to separate, "SetUp()" and "TearDown()" methods. Child fixtures would either subclass the parent fixture, or include the parent using aggregation. In either case, it was the C++ compiler's job to make sure that each class' set up and tear down code was called in the correct order. I have not yet run into a case whereby I needed to have data be shared among several unit tests. If I was doing work with large databases, I might want to do this, however most of the unit tests I’ve needed to write ran fairly quickly.

Just how slow would it be to do a set up and tear down for each test case you are working with? Could some of those cases use mocks instead of a real DB, or is that infeasible?

Regarding hierarchical fixtures, I’ve used such in a C++ library, UnitTest++. With this library, fixtures were still set up as classes, however the set up and tear down code would be placed in the class’ constructor and destructor, as opposed to separate, “SetUp()” and “TearDown()” methods. Child fixtures would either subclass the parent fixture, or include the parent using aggregation. In either case, it was the C++ compiler’s job to make sure that each class’ set up and tear down code was called in the correct order.

]]>