[TIP] Testing with Databases

[Alfredo Deza]

On Sun, Jul 18, 2010 at 11:11 PM, Mark Roddy <markroddy at gmail.com> wrote:

> On Sun, Jul 18, 2010 at 3:08 PM, Alfredo Deza <alfredodeza at gmail.com>
> wrote:
> > Hi,
> > I am building test cases for a middleware app that uses a database to
> store
> > some data.
> > Although I am using MongoDB, my question should be regardless of the
> > database being used.
> > What would you guys recommend to correctly test database behavior related
> to
> > my application?
> > Should I rely on expecting a working database when the application is
> > installed?
> > Is it OK to mock MongoDB? (or any other DB being used). I know mocking is
> OK
> > but might get brittle
> > tests if it gets overused.
> > Maybe even a combination of both: mock some parts but still have certain
> > tests that will definitely require
> > an instance of the database running which could potentially prevent
> version
> > changes that break the app.
> > Any recommendations as to how to deal with database functionality testing
> > would be great.
> >
> > Thanks!
> > _______________________________________________
> > testing-in-python mailing list
> > testing-in-python at lists.idyll.org
> > http://lists.idyll.org/listinfo/testing-in-python
> >
> >
>
> These are my 2 cents as someone whose worked with a lot of db app:
>
> 1) Unit test application side behavior independent of the db.  This
> will likely require mocking, which is ok.
> 2) Write integration tests to execute any database side behavior/logic
> (don't think this would be something needed with mongodb).
> 3) Some set of integration tests should also include application and
> db side to make sure they play nice together.
> 3) When executing tests as part of an automated build/Continuous
> Integration, 'configure' the database along with any test setup prior
> to running about integration tests (such as schema setup and
> sample/test data loading), don't run against an instance sitting
> around as you don't know what state it will be in.  This leads to a
> maintenance headache of having to remember to upgrade the instance and
> has the danger of out of date schema/data causing integration tests to
> pass when they should not.
>
> I answered a similar question on stackoverflow a while back that goes
> a little more in depth:
>
> http://stackoverflow.com/questions/145131/whats-the-best-strategy-for-unit-testing-database-driven-applications/145163#145163
>
> Great answer on StackOverflow, thanks for pointing out how would you
resolve this problem.




> -Mark
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20100719/b82a2e12/attachment.html>