tests pass individually but fail together

[clavie...@gmail.com]

Hello, I'm simplifying a previous post. I just started using Django a few months ago, and for some reason I'm still having trouble getting my mind around the way Django thinks about some things. 

I have a test class that contains two specific tests that always pass when run just by themselves, but always fail when run with the rest of the test class. 

One of the tests in particular is very puzzling, because I can step through the entire method under test and watch everything happen exactly the way it should--the database field values are changed correctly and the correct values are returned. But after the return statement, the values are different than they were before the return statement. They are consistently different, so *something* is happening behind the scenes... but I have no idea what... So I can't tell if my tests are flawed or if my code under test is flawed.

Django 2.0 with MS SQL Server 2014. Any suggestions at all appreciated, because I'm completely out of ideas. I haven't been able to get TransactionTestCase to work at all, though--set-up data that works flawlessly with TestCase breaks TransactionTestCase, and I don't know why. 

Thank you!

Heather

[Dan Tagg]

Hi Heather,

What is it you are testing? I have had issues with this kind of thing when testing forms that are programatically changing dropdown list / default values.

Dan

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/72497524-6c76-41de-ba70-a5b0996335dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Wildman and Herring Limited, Registered Office: 28 Brock Street, Bath, United Kingdom, BA1 2LN, Company no: 05766374

[clavie...@gmail.com]

It's a script that's supposed to run in the background for an inventory management program. The basic idea is that it periodically collects Order objects that are associated with a particular Status (1-M foreign key, though more like 1-1 in practice). Orders have one or many Orderlines. Then it makes all the necessary changes to various quantity fields in various inventory tables. So if an Orderline contains a request for 3 of a particular item, then 3 of that item are reserved in inventory (or backordered or however it needs to go). So far that part has been fine. 

But when that's finished, the Orders and associated Orderlines need updated Statuses. The assert statements say that only some of them were updated, even though I watched them all update correctly--it's like a partial rollback happens before the test finishes. The other failing test checks that the process of updating the statuses also logs the events properly in a History table; but when the test is run as a suite, the event is only partially logged--some records are created and some aren't. But the test results are always consistent for the way the test was run.

So it's just Python and SQL Server--though we do have to use pyodbc to make Django recognize SQL Server, so there's an extra 'layer' there. 

Thank you for the reply, Dan!

Heather

On Thursday, July 5, 2018 at 10:50:49 AM UTC-4, Dan Tagg wrote:

Hi Heather,

What is it you are testing? I have had issues with this kind of thing when testing forms that are programatically changing dropdown list / default values.

Dan

On 5 July 2018 at 14:24, <clavie...@gmail.com> wrote:

Hello, I'm simplifying a previous post. I just started using Django a few months ago, and for some reason I'm still having trouble getting my mind around the way Django thinks about some things. 

I have a test class that contains two specific tests that always pass when run just by themselves, but always fail when run with the rest of the test class. 

One of the tests in particular is very puzzling, because I can step through the entire method under test and watch everything happen exactly the way it should--the database field values are changed correctly and the correct values are returned. But after the return statement, the values are different than they were before the return statement. They are consistently different, so *something* is happening behind the scenes... but I have no idea what... So I can't tell if my tests are flawed or if my code under test is flawed.

Django 2.0 with MS SQL Server 2014. Any suggestions at all appreciated, because I'm completely out of ideas. I haven't been able to get TransactionTestCase to work at all, though--set-up data that works flawlessly with TestCase breaks TransactionTestCase, and I don't know why. 

Thank you!

Heather

--
You received this message because you are subscribed to the Google Groups "Django users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.

To post to this group, send email to django...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/72497524-6c76-41de-ba70-a5b0996335dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Melvyn Sopacua]

On donderdag 5 juli 2018 18:07:58 CEST clavie...@gmail.com wrote:
> It's a script that's supposed to run in the background for an inventory
> management program. The basic idea is that it periodically collects Order
> objects that are associated with a particular Status (1-M foreign key,
> though more like 1-1 in practice). Orders have one or many Orderlines. Then
> it makes all the necessary changes to various quantity fields in various
> inventory tables. So if an Orderline contains a request for 3 of a
> particular item, then 3 of that item are reserved in inventory (or
> backordered or however it needs to go). So far that part has been fine.
>
> But when that's finished, the Orders and associated Orderlines need updated
> Statuses. The assert statements say that only some of them were updated,
> even though I watched them all update correctly--it's like a partial
> rollback happens before the test finishes. The other failing test checks
> that the process of updating the statuses also logs the events properly in
> a History table; but when the test is run as a suite, the event is only
> partially logged--some records are created and some aren't. But the test
> results are always consistent for the way the test was run.

My first instinct is to run the suite with `--parallel 1` and see if that
changes anything. Also, it really helps to have some code - if only to see how
the methods relate to each other if at all.

--
Melvyn Sopacua

[clavie...@gmail.com]

Hi Melvyn,

I've been working on getting permission to post the code, but everybody who can do that is on vacation at present, unfortunately. I'm hoping somebody will be back to work on Monday. I did try the test --parallel 1, but that didn't help.

The problem tests all cover a particular method, and only the first test to run ever passes. Today I wrote a reset method to call at the beginning of each test, and *that* tests out just fine... by itself. I tested it by first calling the other method that seems to be causing issues, then calling the reset method and asserting that all of the records did indeed reset. But when called as a suite, that test fails, too.

I suppose for now I can skip some of the data in setUpTestData and just create brand new records for each test.

Thank you!

Heather