Python and database unittests

[Daniel]

Hello,

I'm writing an application that interacts with a database. As I think
about how to write the unittests, I want them to be able to run
without actually having to access a live database. The pattern that
best describes this is here:

http://martinfowler.com/eaaCatalog/serviceStub.html

I have found http://qualitylabs.org/pdbseed/, which helps with
unittests for a live database. This isn't what I'm after.

Does anyone know about a module that acts as a database stub for
python unittests?

Thanks,
Daniel

[gordyt]

Re: Python and database unittests

Daniel I don't know if it would work for your situation or not, but if
you are using Python 2.5, you could use the now built-in sqlite3
module. If you didn't even want to create a temporary database file
you could use the special memory-only syntax like this:

>>import sqlite3
>>conn =sqlite3.connec t(":memory:")
>># use the connection
>>conn.close( )

--gordy

[Daniel]

Re: Python and database unittests

Hey gordy,

Thanks for the reply. I am actually using sqlite in part of my
application and I don't feel the need to stub that. Even though I
don't use the in memory option, it is still zero configuration so I
build up my database in each test then delete it.

However, the way I interact with the MySQL database is different than
the sqlite portion.

Thanks again,
Daniel


On Aug 26, 4:12 pm, gordyt <gor...@gmail.c omwrote:

Daniel I don't know if it would work for your situation or not, but if
you are using Python 2.5, you could use the now built-in sqlite3
module.  If you didn't even want to create a temporary database file
you could use the special memory-only syntax like this:
>

>import sqlite3
>conn =sqlite3.connec t(":memory:")
># use the connection
>conn.close()

>
--gordy

[alex23]

Re: Python and database unittests

Daniel <daniel.watr... @gmail.comwrote :

Does anyone know about a module that acts as a database stub for
python unittests?

It's not database-specific, but the Mock module should help you here:

http://python-mock.sourceforge.net/

There's even an example on that page for mocking a database.

[Marco Bizzarri]

Re: Python and database unittests

On Wed, Aug 27, 2008 at 4:55 AM, alex23 <wuwei23@gmail. comwrote:

Daniel <daniel.watr... @gmail.comwrote :

>Does anyone know about a module that acts as a database stub for
>python unittests?

>
It's not database-specific, but the Mock module should help you here:
>

http://python-mock.sourceforge.net/

>
There's even an example on that page for mocking a database.
--

http://mail.python.org/mailman/listinfo/python-list

>

--
Marco Bizzarri

http://iliveinpisa.blogspot.com/

[Marco Bizzarri]

Re: Python and database unittests

On Wed, Aug 27, 2008 at 4:55 AM, alex23 <wuwei23@gmail. comwrote:

Daniel <daniel.watr... @gmail.comwrote :

>Does anyone know about a module that acts as a database stub for
>python unittests?

>
It's not database-specific, but the Mock module should help you here:
>

http://python-mock.sourceforge.net/

>
There's even an example on that page for mocking a database.
--

http://mail.python.org/mailman/listinfo/python-list

>

I strongly disagree on using mocks for a database; checking sequences
of SQL statement is fragile, painful, and leads you to frustration
when the actual SQL and the generated SQL do not match.

Regards
Marco

--
Marco Bizzarri

http://iliveinpisa.blogspot.com/

[Marco Bizzarri]

Re: Python and database unittests

On Tue, Aug 26, 2008 at 11:35 PM, Daniel <daniel.watrous @gmail.comwrote :

Hello,
>
I'm writing an application that interacts with a database. As I think
about how to write the unittests, I want them to be able to run
without actually having to access a live database. The pattern that
best describes this is here:
>

http://martinfowler.com/eaaCatalog/serviceStub.html

>
I have found http://qualitylabs.org/pdbseed/, which helps with
unittests for a live database. This isn't what I'm after.
>
Does anyone know about a module that acts as a database stub for
python unittests?
>
Thanks,
Daniel
--

http://mail.python.org/mailman/listinfo/python-list

>

I think you're pointing to the wrong direction, if you want to make a
servicestub; the service should encapsulate your access to the
database (or whatever external resource you want to access), and,
after that, it should be transparent for you, more or less.

Regards
Marco


--
Marco Bizzarri

http://iliveinpisa.blogspot.com/

[Simon Brunning]

Re: Python and database unittests

2008/8/27 alex23 <wuwei23@gmail. com>:

Daniel <daniel.watr... @gmail.comwrote :
It's not database-specific, but the Mock module should help you here:
>

http://python-mock.sourceforge.net/

>
There's even an example on that page for mocking a database.

There's a number of mocking modules for Python - my current favorite
is Mox. See <http://tinyurl.com/57hzr4>.

--
Cheers,
Simon B.
simon@brunningo nline.net

http://www.brunningonline.net/simon/blog/

[Simon Brunning]

Re: Python and database unittests

2008/8/27 Marco Bizzarri <marco.bizzarri @gmail.com>:

I strongly disagree on using mocks for a database; checking sequences
of SQL statement is fragile, painful, and leads you to frustration
when the actual SQL and the generated SQL do not match.

Clearly you need integration tests as well as unit tests, but the unit
tests ought to isolate the code under test, so stubbing out external
dependencies is the norm.

--
Cheers,
Simon B.
simon@brunningo nline.net

http://www.brunningonline.net/simon/blog/

GTalk: simon.brunning | MSN: small_values | Yahoo: smallvalues | Twitter: brunns

[Marco Bizzarri]

Re: Python and database unittests

On Wed, Aug 27, 2008 at 10:26 AM, Simon Brunning
<simon@brunning online.netwrote :

2008/8/27 Marco Bizzarri <marco.bizzarri @gmail.com>:

>I strongly disagree on using mocks for a database; checking sequences
>of SQL statement is fragile, painful, and leads you to frustration
>when the actual SQL and the generated SQL do not match.

>
Clearly you need integration tests as well as unit tests, but the unit
tests ought to isolate the code under test, so stubbing out external
dependencies is the norm.

I agree with you about stubbing external dependencies; I'm just
suggesting to stub the stuff a little further, so that you're not
exposed to actual SQL code.



Regards
Marco

--
Cheers,
Simon B.
simon@brunningo nline.net

http://www.brunningonline.net/simon/blog/

GTalk: simon.brunning | MSN: small_values | Yahoo: smallvalues | Twitter: brunns
--

http://mail.python.org/mailman/listinfo/python-list

>

--
Marco Bizzarri

http://iliveinpisa.blogspot.com/