unittest：添加failUnlessNear的提案 [英] unittest: Proposal to add failUnlessNear

问题描述

我最近一直在进行单元测试，发现

self.failUnlessAlmostEqual，并不是很有用。


我的主要的问题是，它只对有用的物品

可以转换成浮点数，而有一整套

对象可以几乎相等但不是这样

可转换。想到的第一个例子是

复数。


第二个反对意见是你被限制在

a非常具体的集合公差例如，如果你想要确认两个数字最多相差两个数字，那么你不能指定这个数字。


所以我建议添加以下内容

def failUnlessNear（self，first，second，tolerance = 1e-7，msg = None，norm = abs）：

" "如果两个物体距离确定太远，则确定

它们之间的距离和允许的公差。

"""

if norm（second-first）>容忍度：

提高self.failureException，\

（msg或'％s！=％s在％s容差内''％（`first`，`second `，`容忍`））

-

Antoon Pardon

I have been working with unittests lately and found that the
self.failUnlessAlmostEqual, isn''t as usefull as it could be.

My main problem is, that it is only usefull with objects
that can be converted to floats, while there are a whole
bunch of objects that can be almost equal but not so
convertable. The first example coming to mind being
complex numbers.

A secondary objection is that you are limited to
a very specific set of tolerances. If for instance
you want to verify that two numbers differ at most
by 0.0003 you can''t specify that.

So I propose to add the following
def failUnlessNear(self, first, second, tolerance=1e-7, msg=None, norm=abs):
"""Fail if the two objects are too far appart as determined
by the distance between them and the tolerance allowed.
"""
if norm(second-first) > tolerance:
raise self.failureException, \
(msg or ''%s != %s within %s tolerance'' % (`first`, `second`, `tolerance`))
--
Antoon Pardon

推荐答案

On Mon ，2004年7月19日上午11:06:47 +0000，Antoon Pardon写道：

On Mon, Jul 19, 2004 at 11:06:47AM +0000, Antoon Pardon wrote:

我最近一直在进行单元测试，发现
self.failUnlessAlmostEqual，不是尽管很有用。

I have been working with unittests lately and found that the
self.failUnlessAlmostEqual, isn''t as usefull as it could be.

我想听到更多关于你想象的用途，以及

特别是关于如何选择容忍度正确。


杰夫


----- BEGIN PGP SIGNATURE -----

版本： GnuPG v1.2.1（GNU / Linux）

iD8DBQFA ++ LfJd01MZaTXX0RAmGkAJ48vek3HG / xN38Qrhc9dTNAOXlhiwCgqACB

6wvCcYIp0ko8m8dJWDgp9E8 =

= qbcT
-----结束PGP签名-----

I''d like to hear more about the uses you envision about this, and
especially about how to choose "tolerance" properly.

Jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQFA++LfJd01MZaTXX0RAmGkAJ48vek3HG/xN38Qrhc9dTNAOXlhiwCgqACB
6wvCcYIp0ko8m8dJWDgp9E8=
=qbcT
-----END PGP SIGNATURE-----

2004年7月19日11:06:47 GMT，Antoon Pardon < AP ***** @ forel.vub.ac.be>写道：

On 19 Jul 2004 11:06:47 GMT, Antoon Pardon <ap*****@forel.vub.ac.be> wrote:

我最近一直在进行单元测试，发现
self.failUnlessAlmostEqual，并不是有用的。
有用，可以转换成浮点数，而有一堆完整的物体可以几乎相等但不是那么可转换。第一个例子让人联想到复杂的数字。

第二个反对意见是你只能使用一套非常具体的公差。例如，如果你想验证两个数字最多相差
0.0003你就不能指定。

所以我建议添加以下内容

def failUnlessNear（self，first，second，tolerance = 1e-7，msg = None，norm = abs）：
"""如果确定两个对象太远，则失败
它们之间的距离和允许的公差。
"""
if norm（second-first）>容忍度：
提高self.failureException，\
（msg或'％s！=％s在％s容差''％（`first`，`second`，`tolerance`））

-
Antoon Pardon

I have been working with unittests lately and found that the
self.failUnlessAlmostEqual, isn''t as usefull as it could be.

My main problem is, that it is only usefull with objects
that can be converted to floats, while there are a whole
bunch of objects that can be almost equal but not so
convertable. The first example coming to mind being
complex numbers.

A secondary objection is that you are limited to
a very specific set of tolerances. If for instance
you want to verify that two numbers differ at most
by 0.0003 you can''t specify that.

So I propose to add the following
def failUnlessNear(self, first, second, tolerance=1e-7, msg=None, norm=abs):
"""Fail if the two objects are too far appart as determined
by the distance between them and the tolerance allowed.
"""
if norm(second-first) > tolerance:
raise self.failureException, \
(msg or ''%s != %s within %s tolerance'' % (`first`, `second`, `tolerance`))
--
Antoon Pardon

如何更通用的解决方案？例如，如何将可选关键字arg

cmp = comparison_function

传递给failUnlessAlmostEqual？ （我猜这里，没时间看它）

例如，对于混合数字这种方式，包括复杂的你可以（如果你认为

它是有意义的，我不一定在争论;-)使用例如


def special_cmp（x，y）：#untested！

diff = complex（x）-complex （y）

返回最大值（cmp（abs（diff.real），公差），cmp（abs（diff.imag），公差））


并且将cmp = special_cmp作为kwarg传递。


对于特殊对象，您可以定义其他类型的近距离，并且如果您得到非特异性的话，请提高

适当的信息异常 - 可比较的论点。


（显然必须定义公差，所以如果你想方便地改变它，

你可以把它传递给工厂函数那个做上面的def并返回

它在special_cmp引用的闭包中捕获了容差。


或者其他方式。重点是你可以在不修改框架的情况下定义cmp =函数

（一旦实现了可选的kwarg）。）


必须去...


问候，

Bengt Richter

How about a more general solution? E.g., how about an optional keyword arg
cmp=comparison_function
passed to failUnlessAlmostEqual? (I''m guessing here, no time to look at it)
E.g., that way for mixed numbers including complex you could (if you thought
it made sense, which I am not necessarily arguing ;-) use e.g.

def special_cmp(x,y): # untested!
diff = complex(x)-complex(y)
return max(cmp(abs(diff.real), tolerance), cmp(abs(diff.imag), tolerance))

and pass cmp=special_cmp as the kwarg.

For special objects, you could define other kinds of nearness, and raise
appropriate informative exceptions if you get non-comparable arguments.

(obviously tolerance has to be defined, so if you want to vary it conveniently,
you could pass it to a factory function that does the above def and returns
it with tolerance captured in a closure referred to by special_cmp).

Or some other way. The point is you get to define the cmp= function as you please
without modifying the framework (once the optional kwarg is implemented).)

gotta go...

Regards,
Bengt Richter

" Antoon Pardon" < AP ***** @ forel.vub.ac.be>在消息中写道

news：sl ******************* @ trout.vub.ac.be ...

"Antoon Pardon" <ap*****@forel.vub.ac.be> wrote in message
news:sl*******************@trout.vub.ac.be...

我最近一直在进行单元测试，发现
self.failUnlessAlmostEqual，并不是最有用的。

我的主要问题是，它只是有用的与对象
可以转换为浮点数，而有一堆完整的对象可以几乎相等，但不是那么可转换。第一个例子让人联想到复杂的数字。

第二个反对意见是你只能使用一套非常具体的公差。例如，如果你想验证两个数字最多相差
0.0003你就不能指定。


Float和complex有两个非常不同的问题。

因为我维护了FIT的Python端口，所以
不得不处理它们。我为浮动所做的是

使用浮动的字符形式确定

的精度。默认例程附加一个

字符5，然后使用它来计算

范围，其中必须找到另一个值。


一个例子可能有所帮助。假设我想对''6.23e14'进行
测试。这种方法将

建立6.235e14和6.225e14

的界限，然后在这些界限内测试另一个数字是否为
。 （注意在数字转换之前附加的''5'是



浮动，但是第二个界限是计算的

之后转换。）


除了5之外，还有另外一种方式来处理其他

。这种方法是由于$ C $ b Ward Cunningham;我做的是将它从

浮点型适配器移动到ScientificDouble类的基础上。 （Java源代码可以是位于许多地方的
，包括

fit.c2.com和 www.fitnesse.org .Python

源代码位于Extremeprogramming的文件部分

和fitnesse雅虎集团。你们欢迎

来复制这种方法，但是既然Ward把它放在了GPL下的b $ b，我认为它不能直接

投入单位测试。）


复杂，另一方面，应该通过计算 br />
i，j平面中的两个值

然后看看这个距离是否在给定的

范围内。当然，绑定应该是一个可单独指定的参数。


一个主要问题是这些是非常类型的;

这些方法应该被称为

" failUnlessFloatWithinTolerance"并且

failUnlessComplexWithinTolerance。


John Roth


所以我建议添加以下

def failUnlessNear（self，first，second，tolerance = 1e-7，msg = None，
norm = abs）："""如果确定两个对象太远，则失败
它们之间的距离和允许的公差。
"""
if norm（second-first）>容忍度：
提高self.failureException，\
（msg或'％s！=％s在％s容差''％（'first`，
`second`，`tolerance） `））

-
Antoon Pardon

I have been working with unittests lately and found that the
self.failUnlessAlmostEqual, isn''t as usefull as it could be.

My main problem is, that it is only usefull with objects
that can be converted to floats, while there are a whole
bunch of objects that can be almost equal but not so
convertable. The first example coming to mind being
complex numbers.

A secondary objection is that you are limited to
a very specific set of tolerances. If for instance
you want to verify that two numbers differ at most
by 0.0003 you can''t specify that.
Float and complex have two very different issues.
Since I''m maintaining the Python port of FIT, I
had to deal with them. What I did for float was
use the character form of the float to determine
the precision. The default routine appends a
character 5 and then uses this to calculate the
bounds within which the other value must be found.

An example may help. Let''s say I want to
test against ''6.23e14''. This method would
establish bounds of 6.235e14 and 6.225e14
and then test whether the other number was
within those bounds. (Note that the ''5'' is
appended before the numbers are converted
to float, however the second bound is calculated
after the conversion.)

There''s also a way of prescribing something other
than ''5'' to append. This approach is due to
Ward Cunningham; what I did was move it
from the ScientificDouble class to the base
float type adapter. (The Java source can be
located in a number of places, including
fit.c2.com and www.fitnesse.org. The Python
source is in the files section of the Extremeprogramming
and fitnesse Yahoo groups. You''re welcome
to copy the approach, but since Ward put it
under the GPL, I don''t think it can be directly
dropped into unittest.)

Complex, on the other hand, should be dealt
with by calculating the distance between the
two values in the i,j plane
and then seeing if this distance is within a given
bound. The bound should, of course, be a
separately specifiable parameter.

One major issue is that these are very type specific;
the methods should be called something like
"failUnlessFloatWithinTolerance" and
"failUnlessComplexWithinTolerance".

John Roth


So I propose to add the following
def failUnlessNear(self, first, second, tolerance=1e-7, msg=None, norm=abs): """Fail if the two objects are too far appart as determined
by the distance between them and the tolerance allowed.
"""
if norm(second-first) > tolerance:
raise self.failureException, \
(msg or ''%s != %s within %s tolerance'' % (`first`, `second`, `tolerance`))

--
Antoon Pardon

这篇关于unittest：添加failUnlessNear的提案的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！