Comments on: A Program Is Born: QCMake’s First Functional Test http://klimek.box4.net/blog/2007/11/02/a-program-is-born-qcmakes-first-functional-test/ Dedicated to Software Development Fri, 21 Nov 2008 10:46:21 +0000 http://wordpress.org/?v=2.5.1 By: Adrian Smith http://klimek.box4.net/blog/2007/11/02/a-program-is-born-qcmakes-first-functional-test/#comment-10887 Adrian Smith Fri, 02 Nov 2007 09:27:31 +0000 http://klimek.box4.net/blog/2007/11/02/a-program-is-born-qcmakes-first-functional-test/#comment-10887 Yeah I usually find some test utilities are required to write test scripts. Recursively removing a directory would seem to be one of them, as it's possible/plausible/likely you'll need this from multiple tests. Or even from the main program. Or another main program you'll write some day. I work a lot with website software which provide most of their functionality when the user is logged in. So I always create dummy users to perform tests on. This often takes a few lines (e.g. handling things like unique constraints on email addresses, etc.). This is certainly code shared between multiple tests. Sometimes I need to create products and baskets to attempt various algorithms. This is also code not specific to a single test (even if it happens only to be used by one test at the time I need it first). So I tend to extend e.g. the "User" class with a static function like "CreateForTesting". The "ForTesting" is a hint that it's not intended to be called from the main program. This means that all test scripts have access to this functionality rather than having it duplicated amongst multiple tests. And for me it just seems to be a function of a User, that the User software is able to create a dummy version of a User. So it's appropriate to put it there. And if you need to change the user, you'll consider updating that function. It's certainly extremely convenient to program that way. A bunch of classes can create useful test instances of themselves. This goes against some "best practice" wisdom, that test code should be separate from live code. But as far as I'm concerned code locality is good, and a class has multiple clients anyway, and a test script is just another one of them. Yeah I usually find some test utilities are required to write test scripts. Recursively removing a directory would seem to be one of them, as it’s possible/plausible/likely you’ll need this from multiple tests. Or even from the main program. Or another main program you’ll write some day.

I work a lot with website software which provide most of their functionality when the user is logged in. So I always create dummy users to perform tests on. This often takes a few lines (e.g. handling things like unique constraints on email addresses, etc.). This is certainly code shared between multiple tests. Sometimes I need to create products and baskets to attempt various algorithms. This is also code not specific to a single test (even if it happens only to be used by one test at the time I need it first). So I tend to extend e.g. the “User” class with a static function like “CreateForTesting”. The “ForTesting” is a hint that it’s not intended to be called from the main program.

This means that all test scripts have access to this functionality rather than having it duplicated amongst multiple tests. And for me it just seems to be a function of a User, that the User software is able to create a dummy version of a User. So it’s appropriate to put it there. And if you need to change the user, you’ll consider updating that function. It’s certainly extremely convenient to program that way. A bunch of classes can create useful test instances of themselves.

This goes against some “best practice” wisdom, that test code should be separate from live code. But as far as I’m concerned code locality is good, and a class has multiple clients anyway, and a test script is just another one of them.

]]>