Re: tests pass individually but fail together

2018-07-06 Thread clavierplayer
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

On Thursday, July 5, 2018 at 3:19:48 PM UTC-4, Melvyn Sopacua wrote:
>
> 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 
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@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/0103df45-5800-4751-b138-b50d9f354dae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: tests pass individually but fail together

2018-07-05 Thread Melvyn Sopacua
On donderdag 5 juli 2018 18:07:58 CEST clavierpla...@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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@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/18693819.ysi9JWK4Ts%40fritzbook.
For more options, visit https://groups.google.com/d/optout.


Re: tests pass individually but fail together

2018-07-05 Thread clavierplayer
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, > 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.
>>
>
>
>
> -- 
> Wildman and Herring Limited, Registered Office: 28 Brock Street, Bath, 
> United Kingdom, BA1 2LN, Company no: 05766374
>

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@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/816a9e74-ff3a-40d7-a570-91d0339cc1da%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: tests pass individually but fail together

2018-07-05 Thread 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

On 5 July 2018 at 14:24,  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+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@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/CAPZHCY5UPA79U1N%2Bkk6XzqvejjdXuzh73tzBi-pQNMPPqpx8ZA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


tests pass individually but fail together

2018-07-05 Thread clavierplayer
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@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.