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