On 03/11/2014 01:58 PM, Ethan Furman wrote:
So I finally got enough data and enough of an understanding to write some unit
tests for my code.
The weird behavior I'm getting:
- when a test fails, I get the E or F, but no summary at the end
(if the failure occurs in setUpClass before
On 3/12/2014 11:32 AM, Ethan Furman wrote:
I strongly suspect it's memory. When I originally wrote the code I
tried to include six months worth of EoM data, but had to back it down
to three as my process kept mysteriously dying at four or more months.
There must be waaay too much stuff bein
On 03/12/2014 04:38 PM, Steven D'Aprano wrote:
[snip lots of good advice for unit testing]
I was just removing the Personally Identifiable Information. Each test is pulling a payment from a batch of payments,
so the first couple asserts are simply making sure I have the payment I think I hav
On 03/12/2014 04:47 PM, Steven D'Aprano wrote:
top -Mm -d 0.5
Cool, thanks!
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
On Wed, 12 Mar 2014 08:32:29 -0700, Ethan Furman wrote:
>> Some systems have an oom (Out Of Memory) process killer, which nukes
>> (semi-random) process when the system exhausts memory. Is it possible
>> this is happening? If so, you should see some log message in one of
>> your system logs.
>
On Tue, 11 Mar 2014 13:58:17 -0700, Ethan Furman wrote:
> class Test_wfbrp_20140225(TestCase):
>
> @classmethod
> def setUpClass(cls):
> cls.pp = wfbrp.PaymentProcessor(
> '.../lockbox_file',
> '.../aging_file',
> [
> Path
On Wed, 12 Mar 2014 08:32:29 -0700, Ethan Furman wrote:
> There must
> be waaay too much stuff being kept alive by the stack traces of the
> failed tests.
I believe that unittest does keep stack traces alive until the process
ends. I thought that there was a recent bug report for it, but th
In article ,
Ethan Furman wrote:
> > Alternatively, maybe something inside your process is just calling
> > sys.exit(), or even os._exit(). You'll see the exit() system call in
> > the strace output.
>
> My bare try/except would have caught that.
A bare except would catch sys.exit(), but not
On 03/12/2014 06:44 AM, Roy Smith wrote:
In article ,
Ethan Furman wrote:
I've tried it both ways, and both ways my process is being killed, presumably
by the O/S.
What evidence do you have the OS is killing the process?
I put a bare try/except around the call to unittest.main, with a pr
In article ,
Ethan Furman wrote:
> I've tried it both ways, and both ways my process is being killed, presumably
> by the O/S.
What evidence do you have the OS is killing the process?
Some systems have an oom (Out Of Memory) process killer, which nukes
(semi-random) process when the system e
On 03/11/2014 08:36 PM, Terry Reedy wrote:
On 3/11/2014 6:13 PM, John Gordon wrote:
In Ethan Furman
writes:
if missing:
raise ValueError('invoices %r missing from batch' % missing)
It's been a while since I wrote test cases, but I recall using the assert*
methods (
On 3/11/2014 6:13 PM, John Gordon wrote:
In Ethan Furman
writes:
if missing:
raise ValueError('invoices %r missing from batch' % missing)
It's been a while since I wrote test cases, but I recall using the assert*
methods (assertEqual, assertTrue, etc.) instead of ra
On 03/11/2014 03:13 PM, John Gordon wrote:
Ethan Furman writes:
if missing:
raise ValueError('invoices %r missing from batch' % missing)
It's been a while since I wrote test cases, but I recall using the assert*
methods (assertEqual, assertTrue, etc.) instead of raisin
On 03/11/2014 01:58 PM, Ethan Furman wrote:
Anybody have any ideas?
I suspect the O/S is killing the process. If I manually select the other class to run (which has all successful tests,
so no traceback baggage), it runs normally.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/pyth
In Ethan Furman
writes:
> if missing:
> raise ValueError('invoices %r missing from batch' % missing)
It's been a while since I wrote test cases, but I recall using the assert*
methods (assertEqual, assertTrue, etc.) instead of raising exceptions.
Perhaps that's the issue?
15 matches
Mail list logo
