On Feb 25, 10:31 am, Jeremy Dunck <jdu...@gmail.com> wrote: > On Sat, Feb 25, 2012 at 2:13 AM, Anssi Kääriäinen > > <anssi.kaariai...@thl.fi> wrote: > > I think you really should use a transactional test case. The reason is > > that before you do a commit, your writes really should not be visible. > > Hiding this in testing could lead to hiding bugs. > > Of course that is the case, but here the transaction is artificial - > part of the runner, not of the code under test. All that using > TransactionTestCase does is side-step the pending transaction, not > model the code under test more accurately.
It is hard for the runner to know if transactions matter or not. I can see that if you just want to read the slave to verify something written to the master then the transactions hinders you. On the other hand, if you test some part of your code which uses multiple databases, using a shared connection can lead to hidden bugs. For example a view could write to the master database, then return what is written from the slave database. If you share the connection it works, if not it will not work. The problem is that transactions _are_ allowed when using TestCase. They just do not do anything. So, the TestCase doesn't know if the transaction is artificial or not. If the transactional methods were error-raising instead of no-ops then the situation might be different. Even then, you are likely testing code that will be ran inside transaction even if the code itself doesn't explicitly start one. Again, hidden bugs is the result. One more reason: if you would change your database setup in a way that you are actually using proper master-slave database setup for testing you would get problems. For example you could do this in Jenkins integration tests where the more complex database setup and overhead isn't a big problem. Any tests which depended on connection sharing will fail in the integration server. - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
