A thought on DAO test data insert verification

[Mark Wilkie]

I have noticed that is some places we are verifying DAO test insert data by utilizing the DAO to pull data after an insert. This was in an older DAO test that I am transforming, but seemed worth wile to discuss...example (with quasi sudo-codish like syntax):

testOfStuff() {

$stuff_dao->insertStuff($name, $email);

$some_data = $stuff_dao->getStuffByEmail($email);

// assertions based on data returned from DAO getStuffByEmail() call...

}

So in this case we are verifying that "stuff" data was inserted properly by making a getStuffByEmail() call to the same StuffDAO.

I would argue that we should avoid using DAO calls to verify data insertion in a test. I suggest a better test example would be something like:

testOfStuff() {

$stuff_dao->insertStuff($name, $email);

$stmt = $pdo->query( "select * from stuff where email = ' . $email);
$data = $stmt->fetch();

// assertions based on $data...

}

this way we keep the tests as discreet as possible and avoid relying on other functionality to test our specific insert code.

-Mark

[Christoffer Viken]

I usually put the get tests above the insert tests...

If the get can't catch the record you inserted, it shouldn't pass anyway, if the test of the get didn't catch it... there is that more reason for the failure at the other level...

The beauty of using the DAO is that tests too can be ported pretty fast (edit SetUp and TearDown)

--
You received this message because you are subscribed to the Google Groups "ThinkTank App" group.
To post to this group, send email to thinkt...@googlegroups.com.
To unsubscribe from this group, send email to thinktankapp...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/thinktankapp?hl=en.

[Mark Wilkie]

I would strongly argue that unit tests should be as discrete as possible, and should avoid relying on other tests or code whenever possible.

Here is a simple example where this could be problematic:

- You hack up some "get" code that returns a bool=false where is should be returning a true, but your test doesn't catch the problem.

- You then add an "insert" call that is failing to insert proper data to return a bool=false value, but the "get" returns false so you think your test is passing properly because of the bad "get" method.

- The dependance of the "insert" test on the bad "get" code now introduces two bugs instead of one.

Our Mysql DAO tests really should make calls directly to the db to verify insert/update data to reduce the risk of other DAO code mudding the test results, and to verify with better certainty that our persistence code is functioning as designed. It is basically the inverse of how we set up data to test our "get" code.

This will also help keep fail messages directed to the actual tests that are failing, so instead of getting a list of fails for the "get", "insert" and "update" tests you only get fails for "get" code that is actually failing.

-m

[Gina Trapani]

On Sun, Jun 20, 2010 at 10:41 AM, Mark Wilkie <ma...@bitterpill.org> wrote:
> I would strongly argue that unit tests should be as discrete as possible, and should avoid relying on other tests or code whenever possible.

Yes it's a valid point, and I agree (even though I have done it the
"lazy way" so far).

There are dozens of books written about testing best practices, and I
don't want to rewrite those. But now that we're getting disciplined
about testing, it's worth documenting the things I'll look for on pull
requests. I've started a developer guide including this point and one
other:

http://wiki.github.com/ginatrapani/thinktank/developer-guide-how-to-write-great-unit-tests

--
http://ginatrapani.org
http://twitter.com/ginatrapani

[Christoffer Viken]

You can never avoid consequent errors, 

the good thing about using existing code is that if you for some reason choose to change the underlying data structure (rename a table or something). You do not need to skim trough all the tests (on top of the DAOs).

As for triggering more than one error/testfail... Does it matter in a zero-fail environment?

I can see the issue if we wrote tests for open tickets, but we are operating in an environment where all the tests pass.

I would personally go about looking for a fix starting at one end (after skimming trough the list). 

Then look at the test that failed. 

When I see that it fetches trough another method, and i vaguely remember that method being on the fail list, i would skip to that one instead. (by the way i would never start at that end, I am careful to test methods other tests rely on before the tests that rely on them in the first place, and i always start on the top for some reason :p)

If the only insert test fails, and the reason it failed is a get-method error, You have uncovered a get-method bug that needs to be fixed anyway. If both fail, See above.

Yes sure you can reinvent the wheel... But do you really need to bother? It is just extra work for you and the person that down the road needs to rename something in the database.

I certainly can live with consequent errors popping up if You/I/We break something. And I am not going to go to great (or anything longer than "very short") lengths to avoid them, I can see that thee can be benefits, but are they really worth it? 

One fail is just as bad as 20 right? So if one method breaks, and 20 fails result (and only 5 is related to the test of the method itself) 

So then you have 15 failures that magically disappears once you fix the first method.

----------Desktop Browser---------
Christoffer Viken / CVi
for($i=0;$i<=21;$i++){if(($i%3)&&!($i%4)){print(substr("kI4dJMtXAv0m3cUiPKx8H",$i,1));}}