Unit Testing and NOW()

[Trevor Morse]

Hi Everyone,

I guess I'll be the one to break our question asking cherry. :-)

I don't know if any of you have used or are using phpunit for testing,
but here's my problem.

I am using phpunit and more specifically it's database extension to
test some code I am writing. This allows you to run some code, then
use an XML file to compare what's in the database with what should be
in the database. Which works great and is pretty cool, as long as you
do not have dynamic data.

Of course when you are updating rows in the table it is changing the
update date field and populating it using NOW(). So I can't find any
way to test this with the database extension.

I'm moving on to using regular unit test to validate the date/time
stamps but the only way I can think of to do that is to check for date/
time stamps in the last 30 seconds(or whatever interval is
reasonably). This seems kind of hokey though.

Any ideas/suggestions from anyone on a better approach?

Thanks,

Trevor

[Trevor Morse]

Hey Jonathan,

Thanks for the response! See my follow up below.

On Sun, Oct 25, 2009 at 11:49 AM, Jonathan <jjmo...@gmail.com> wrote:
>
> Yeah if dynamic data is what you're testing, I'd lose the XML file.
> But I think you should ask yourself why you would want to test MySQL's
> NOW() function.  You didn't write the code, and it's a pretty good bet
> the people at MySQL tested the function thoroughly.  All your code
> does is call the function.  If you had somehow written a stored
> procedure that extended the functionality of NOW(), I'd test that --
> it's your code, you should prove it works.

Well, what we are using is a function that actually creates the proper
database function based on the type of database(MySQL, Oracle, etc) we
are using. With hopes of becoming database independent in the future,
so there is some functionality I am testing there other then just
MySQL's NOW() function. :-)

>
> The only situation I see testing being useful is to make sure that
> you've populated the timestamp field at all, in which case you might
> test that the field is not NULL or whatever the default value.
>
> Reasonable?

What I actually ended up doing is sticking with the XML file for data
and using phpunit's db extensions filtering capability to ignore the
created and updated fields when using the db extension to compare. You
can get more info here -
http://www.digitalsandwich.com/archives/78-Improved-PHPUnit-Filters.html.
I then figure out the current time, do a quick query to the database
and pull back the created/updated dates and make sure they happened in
the last 10 secs.

Make sense?

Cheers,

Trevor

[George Anderson]

Like mentioned, I think testing NOW() is not really needed since its
already been tested by MySQL and I think its safe to assume that this
works properly. I would just make sure that the field is actually
being populated and its not NULL. The data would have to be static if
you wanted decent test results. Dealing with dynamic data is tricky
to test when using the XML method. Just my 2cents. Maybe try the
forums to see if anyone has been dealing with the same issue?

On Oct 25, 4:47 pm, Trevor Morse <trevor.mo...@gmail.com> wrote:
> Hey Jonathan,
>
> Thanks for the response! See my follow up below.
>

> On Sun, Oct 25, 2009 at 11:49 AM, Jonathan <jjmon...@gmail.com> wrote:
>
> > Yeah if dynamic data is what you're testing, I'd lose the XML file.
> > But I think you should ask yourself why you would want to test MySQL's
> > NOW() function.  You didn't write the code, and it's a pretty good bet
> > the people at MySQL tested the function thoroughly.  All your code
> > does is call the function.  If you had somehow written a stored
> > procedure that extended the functionality of NOW(), I'd test that --
> > it's your code, you should prove it works.
>
> Well, what we are using is a function that actually creates the proper
> database function based on the type of database(MySQL, Oracle, etc) we
> are using. With hopes of becoming database independent in the future,
> so there is some functionality I am testing there other then just
> MySQL's NOW() function. :-)
>
>
>
> > The only situation I see testing being useful is to make sure that
> > you've populated the timestamp field at all, in which case you might
> > test that the field is not NULL or whatever the default value.
>
> > Reasonable?
>
> What I actually ended up doing is sticking with the XML file for data
> and using phpunit's db extensions filtering capability to ignore the
> created and updated fields when using the db extension to compare. You

> can get more info here -http://www.digitalsandwich.com/archives/78-Improved-PHPUnit-Filters.html.

[Jonathan]

>
> Well, what we are using is a function that actually creates the proper
> database function based on the type of database(MySQL, Oracle, etc) we
> are using. With hopes of becoming database independent in the future,
> so there is some functionality I am testing there other then just
> MySQL's NOW() function. :-)

That's cool. I really thought there was more to it than I was
reading. Removing dependency is always great.

> What I actually ended up doing is sticking with the XML file for data
> and using phpunit's db extensions filtering capability to ignore the
> created and updated fields when using the db extension to compare. You

> can get more info here -http://www.digitalsandwich.com/archives/78-Improved-PHPUnit-Filters.html.

> I then figure out the current time, do a quick query to the database
> and pull back the created/updated dates and make sure they happened in
> the last 10 secs.
>
> Make sense?

Lol, somewhat. I've used phpunit only once that I can remember, but
not with the XML or DB extensions. Even then it was for my own
project, and not at work. Unfortunately most of the code I deal with
is inline and not easily tested, and the projects are so small there
is little room for automated testing.