help：单元测试夹具返回相同的对象 [英] help: Unit test fixture returning the same object
问题描述
我对unittest.TestCase有一个问题，我真的可以使用
一些帮助。
我在模块文件中有一个类文件。关于文件的重要事项
这个讨论就是它很简单 - 不涉及任何对象池，
和随后的File.File调用（''filename ''）应该返回
不同的对象（实际上，它们在命令行上执行）。另外，
__repr__打印出文件的id（self）值，所以我可以告诉
这里发生了什么......
我还有一套测试，测试testFile.py中的文件
其中，我有一个看起来像这样的TestCase子类：
class FileReadingTestCase（unittest.TestCase）：
def setUp（self）：
self.testfilename =" filename"
self。 testfile = File.File（self.testfilename）
print''setup：''，self.testfile
def tearDown（self）：
print''teardown：''，self.testfile
self.testfile.close（）
self.testfile =无
print''teardown：''，self.testfile
....然后是一堆使用self.testfile的测试。
问题是在每个测试用例中，setUp和tearDown被称为
，根据打印语句的预期，但他们似乎没有b
任何ef第一次调用后的fect。 self.testfile总是
与id（）报告的实例相同。
这里有两件奇怪的事情：
1 - 在tearDown（）中，self.testfile确实被设置为None，但在
中后续调用setUp（），self.testfile指向右边
回到同一个对象。
2 - 当然，你不能在setUp（）
之前打印self.testfile的值已分配，按预期工作，但在调用文件的
构造函数时，您将获得具有相同ID的相同对象。
这不会不会发生在任何其他情况下，所以我认为有一些关于单元测试框架（或者只是Python）的东西我不会理解。有没有人有任何见解？
我的python是2.3，与Mac OS X 10.3一起分发
谢谢，
-mike
Hi, I have a problem with unittest.TestCase that I could really use
some help with.
I have a class File in module File. The important thing about File for
this discussion is that it''s simple - no pool of objects are involved,
and subsequent invocations of File.File(''filename'') should return
distinct objects (and indeed, they do on the command line). Also,
__repr__ prints out the value of id(self) for File, so I can tell
what''s going on here..
I also have a suite of tests that test File in testFile.py
Within, I have a TestCase subclass that looks like this:
class FileReadingTestCase(unittest.TestCase):
def setUp(self):
self.testfilename = "filename"
self.testfile = File.File(self.testfilename)
print ''setup:'', self.testfile
def tearDown(self):
print ''teardown:'', self.testfile
self.testfile.close()
self.testfile = None
print ''teardown:'', self.testfile
.... followed by a bunch of tests that use self.testfile.
The problem is that in each test case, setUp and tearDown are called
as expected according to the print statements, but they don''t seem to
have any effect after the first invocation. self.testfile is always
the same instance as reported by id().
There are two strange things going on here:
1 - in tearDown(), self.testfile is indeed being set to None, but in
the subsequent invocation of setUp(), self.testfile is pointing right
back to the same object.
2 - Of course, you can''t print the value of self.testfile in setUp()
before it''s assigned, that works as expected, but when calling the
constructor for File, you get the same object with the same id.
This doesn''t happen in any other context, so I think there is
something about the unittest framework (or just Python) that I don''t
understand. Does anyone have any insight?
my python is 2.3, as distributed with Mac OS X 10.3
Thanks,
-mike
推荐答案
文章< 98 ******************** ******@posting.google.com>，
mi * **************@mac.com （Michael McCracken）写道：
In article <98**************************@posting.google.com >,
mi***************@mac.com (Michael McCracken) wrote:
问题是在每个测试用例中，setUp根据印刷声明，可以按照预期称为泪滴，但是在第一次调用后它们似乎没有任何效果。 self.testfile总是与id（）报告的实例相同。
The problem is that in each test case, setUp and tearDown are called
as expected according to the print statements, but they don''t seem to
have any effect after the first invocation. self.testfile is always
the same instance as reported by id().
你真的确定它们是同一个对象吗？ id（）只返回内存中对象的
地址。只要它们的生命周期不重叠，两个对象就有可能具有相同的id。如果你反复地在同一个环境中创建和销毁相同类型的对象（因为在单元测试环境中发生了
），那么对象的合理可能性很大$>
将重用相同的内存位置。
除了id（）的奇怪之处在不同的
测试中返回相同的值，是意外发生了什么？
Are you really sure they''re the same object? id() just returns the
address of the object in memory. It''s possible for two objects to have
the same id as long as their lifetimes never overlap. If you repeatedly
create and destroy the same type of objects in the same context (as
happens in a unittest environment), it''s reasonably likely that objects
will reuse the same memory locations.
Other than the oddity of id() returning the same value in different
tests, is something unexpected happening?
Michael McCracken写道：
Michael McCracken wrote:
问题是在每个测试用例中，setUp和tearDown被称为<正如预期的那样根据印刷声明，但在第一次调用后它们似乎没有任何影响。 self.testfile总是与id（）报告的实例相同。
The problem is that in each test case, setUp and tearDown are called
as expected according to the print statements, but they don''t seem to
have any effect after the first invocation. self.testfile is always
the same instance as reported by id().
Roy说的......但要向自己证明，如果你需要，
只需在
文件__init__方法中实现一个基于类变量的小计数器，以显示你变得不同
对象每一次。 （也就是说，每次通过__init__时，都会增加一个全局计数器
，并将实例中的当前
计数存储起来，以便在您执行时检索并显示>
正在打印对象的ids（）。
-Peter
What Roy said... but to prove it to yourself, if you need to,
just implement a little class-variable-based counter in the
File __init__ method to show that you are getting different
objects each time. (That is, increment a global counter
each time you go through __init__, and store the current
count in the instance, to be retrieved and shown when you
are printing the ids() for the objects.)
-Peter
Peter Hansen< pe ***@engcorp.com>在消息新闻中写道：< nK ******************** @ powergate.ca> ...
Peter Hansen <pe***@engcorp.com> wrote in message news:<nK********************@powergate.ca>...
Michael McCracken写道：
Michael McCracken wrote:
问题是，在每个测试用例中，setUp和tearDown按照打印语句按预期调用
，但它们似乎没有任何
第一次调用后的效果。 self.testfile总是与id（）报告的实例相同。
The problem is that in each test case, setUp and tearDown are called
as expected according to the print statements, but they don''t seem to
have any effect after the first invocation. self.testfile is always
the same instance as reported by id().
罗伊所说的......但要向自己证明，如果你需要，<只需在
File __init__方法中实现一个基于类变量的小计数器，以显示每次都得到不同的对象。 （也就是说，每次通过__init__时都会增加一个全局计数器，并将当前的
计数存储在实例中，以便在您打印ids（）时检索并显示对象。）
-Peter
What Roy said... but to prove it to yourself, if you need to,
just implement a little class-variable-based counter in the
File __init__ method to show that you are getting different
objects each time. (That is, increment a global counter
each time you go through __init__, and store the current
count in the instance, to be retrieved and shown when you
are printing the ids() for the objects.)
-Peter
感谢您的回复！
我想我得到了非常接近解决方案，但我会很感激
更多的帮助。
所以，我仍然很惊讶id（）会指出每个
时间对同一个对象，但我愿意相信它。但是，我不认为这只是'
'唯一正在发生的事情 - 我在第一个
地方注意到这一点的原因是setUp方法在我的File对象中打开一个文件并填充一些
列表，这些列表在测试方法之间累积了对象
。
第一个测试看到文件正如它所期望的那样，而第二个测试看到
a带有列表成员变量的文件，其中每个
对象的读取次数是等等。这就是为什么我愿意相信
，同样的id（）不是侥幸。
我确实尝试了全球计数的想法，而且我确实得到了越来越多的计数，尽管有着相同的id怪异，但是还是b $ b。因此，新实例似乎正在创建具有相同数据结构的
。我不认为我不小心使用类变量使用
，这是我唯一能想到的。任何
更多提示？
谢谢，
-mike
Thanks for the responses!
I think I''m getting pretty close to the solution, but I''d appreciate
some more help.
So, I''m still surprised that id() would point to the same object every
time, but I''m willing to believe it. However, I don''t think that''s the
only thing that''s going on - the reason I noticed this in the first
place is that the setUp method was opening a file and populating some
lists in my File object, and those lists were accumulating objects
between test methods.
The first test sees the File as it expects, while the second one sees
a File with list member variables that have twice as many of each
object it reads in, and so forth. That''s why I was willing to believe
that the same id() wasn''t a fluke.
I did try the global count idea, and I did get an increasing count,
despite the same id oddity. So new instances seem to be getting
created, with the same data structures. I don''t think I''m accidentally
using class variables, and that is the only thing I can think of. Any
more tips?
Thanks,
-mike
这篇关于help：单元测试夹具返回相同的对象的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
