Testing DB insert?

Discussion of testing theory and practice, including methodologies (such as TDD, BDD, DDD, Agile, XP) and software - anything to do with testing goes here. (Formerly "The Testing Side of Development")

Moderator: General Moderators

Post Reply
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Testing DB insert?

Post by alex.barylski »

I should probably read more about how AUT's work, but I can't help but ask:

When testing a SQL function, say:

Code: Select all

create_user($fname, $lname, $age, $sex, $addres = '')
I would include the nessecary model classes, etc inside my unit test...I would pass several amounts of data to create_user() possibly by doing something like:

Code: Select all

create_user('Ted', 'Bindy', 23, 'M', '123 Test Street');
create_user('Ted', 'Bundy', 23, 'M', '123 Test Street');
create_user('Ted', 'Binder', 23, 'M', '123 Test Street');
create_user('Ted', 'Bunter', 23, 'M', '123 Test Street');
The way I see it, I have two options for calling these functions:

1) I setup a test DB
2) I use the production DB, but...

Code: Select all

$r1 = create_user('Ted', 'Bindy', 23, 'M', '123 Test Street');
$r2 = create_user('Ted', 'Bundy', 23, 'M', '123 Test Street');
$r3 = create_user('Ted', 'Binder', 23, 'M', '123 Test Street');
$r4 = create_user('Ted', 'Bunter', 23, 'M', '123 Test Street');

delete_user($r1);
delete_user($r2);
delete_user($r3);
delete_user($r4);
Thus in my test I would be killing two birds with one stone...

However I'm getting the impression from what I've read that I would ideally keep tests atomic...

So the better method is to use a test database, testing create methods on their own...

And in the delete test's I would just have to create a temporary user and then delete???

Which way is the suggested norm???

Cheers :)
User avatar
sweatje
Forum Contributor
Posts: 277
Joined: Wed Jun 29, 2005 10:04 pm
Location: Iowa, USA

Post by sweatje »

Have your setup() method drop and recreate a blank database schema for each test, then you are working from a known state.
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

sweatje wrote:Have your setup() method drop and recreate a blank database schema for each test, then you are working from a known state.
Ahhh...thats what setUp() and tearDown() are for??? :idea:

So in my test object, why couldn't I just do that in the ctor/dtor??? :?

Do setUp/tearDown exist for backword compatability for testing PHP 4 objects???

I could use ctor/dtor to create and destroy my envinment correct?

So it would then be best if I created:
1) Database
2) Schema
3) Record

The inside dtor() I would just drop the database??? Makes sense :)
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post by Chris Corbyn »

Hockey wrote:
sweatje wrote:Have your setup() method drop and recreate a blank database schema for each test, then you are working from a known state.
Ahhh...thats what setUp() and tearDown() are for??? :idea:

So in my test object, why couldn't I just do that in the ctor/dtor??? :?
Because setUp() and tearDown() run before and after each test *method* not before and after the test object lifetime.
Do setUp/tearDown exist for backword compatability for testing PHP 4 objects???

I could use ctor/dtor to create and destroy my envinment correct?

So it would then be best if I created:
1) Database
2) Schema
3) Record

The inside dtor() I would just drop the database??? Makes sense :)
No, you've misunderstood what they do:

Code: Select all

class TestOfNothingAtAll extends UnitTestCase
{
    public function setUp()
    {
        echo "setUp() called<br />";
    }

    public function tearDown()
    {
        echo "tearDown() called<br />";
    }
    
    public function testPointlessness()
    {
        $this->assertTrue(true);
    }

    public function testNothingness()
    {
        $this->assertNull(null);
    }
}
alex.barylski
DevNet Evangelist
Posts: 6267
Joined: Tue Dec 21, 2004 5:00 pm
Location: Winnipeg

Post by alex.barylski »

Because setUp() and tearDown() run before and after each test *method* not before and after the test object lifetime.
Ok, so your supposed to create/destroy your envinroment before and after every method???

What do you do if more than one method uses the same environment?
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post by feyd »

If your method cleans up after itself returning the environment to it's original state you don't need the setup()/teardown() methods. Although if your method alters the records, in this case, then let the setup() and teardown() do their jobs.
User avatar
sweatje
Forum Contributor
Posts: 277
Joined: Wed Jun 29, 2005 10:04 pm
Location: Iowa, USA

Post by sweatje »

Hockey wrote: Ok, so your supposed to create/destroy your envinroment before and after every method???

What do you do if more than one method uses the same environment?
Every method should use the same environment, the question becomes how much interferance do you want to have between the tests? Can the results of one method impact another test? The last thing you want to do is be debugging your test suite. One way (fairly draconian) is to simply drop and recreate the schema for each test. Do you need some base data populated? Create a helper method to do the additions, and call it when you have a method which wants to see the data. Is there seed data which should always be populated? Just make that part of the setup() to recreate it.
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

Of course, doing that too much can make things reeeeaaaaaallllyyyy ssssllllllooooooowwwwwwww... . . .
User avatar
feyd
Neighborhood Spidermoddy
Posts: 31559
Joined: Mon Mar 29, 2004 3:24 pm
Location: Bothell, Washington, USA

Post by feyd »

They're tests. They don't need to be fast. :P
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post by timvw »

These days i use a separate schema for unittesting...

Each test goes as following:

- start transaction
- load required data
- perform method to test
- assert that method did what it had to do
- rollback transaction

When i notice there is to much initial loading of required data i can decide to store the data permanent (and leave the loading step out).
Post Reply