单元测试艺术 [英] Art of Unit Testing
问题描述
2001年8月，有一个关于单位测试艺术的帖子：
http://groups.google.com/group/comp....a29faf0a0485d5
保罗·摩尔问了一个合理的问题，为什么没有任何关于全球的问题。整个TestCase仅运行一次的fixture代码，因为
与普通的setUp相反和tearDown在TestCase中为每个
单个测试运行的代码。 全局固定装置在创建灯具时耗时很长，例如
。你必须创建一个数据库连接甚至是整个数据库。
这些全球设备的首选解决方案是什么？只需
创建数据库，运行TestCase，然后删除数据库？
添加globaleSetup是否有意义和globalTearDown方法
到TestCase类？我认为至少它不会伤害任何人。
应该提交这样的提案吗？
- Christoph Zwerschke
< blockquote> py.test模块提供方法，类和
模块级别的设置/拆除挂钩。您正在描述的场景将在
模块级别进行介绍。有关详细信息，请参阅py.test文档：
< http://codespeak.net/py/current/doc/test.html#managing-test-state-across-test-modules- class-and-methods>
Grig
====
http://agiletesting.blogspot.com
Christoph Zwerschke< ; ZW ******* @ zuv.uni-heidelberg.de>写道：
添加globaleSetup是否有意义？和globalTearDown方法
到TestCase类？我认为至少它不会伤害任何人。这些提案应该在哪里提交？
一般而言，这不是一个好主意。如果你构建像
这样的测试，很难知道哪个测试真的出错了，你可能会得到整个测试工作的情况，但是在某种程度上取决于每一个
。 （这也可能由于更加模糊的原因而发生，并且
值得关注你的任何一种方式。）
所以，重建环境为每一次测试之前每次测试都需要额外的费用。
-
Bj ?? rn Lindstr ?? m< ; bk ** @ stp.lingfil.uu.se>
计算语言学学生，瑞典乌普萨拉大学
"" Bj Lindstr ?? m" < BK ** @ stp.lingfil.uu.se>在消息中写道
news：87 ************ @ lucien.dreaming ...Christoph Zwerschke< zw **** ***@zuv.uni-heidelberg.de>写道：
添加globaleSetup是否有意义？和globalTearDown方法
到TestCase类？我认为至少它不会伤害任何人。这些提案应该在哪里提交？
总的来说，这不是一个好主意。如果你构建像
那样的测试，很难知道哪个测试确实出错了，你可能会得到整套测试工作的情况，但是依赖于每一个测试。某种程度上来说。 （这也可能由于更加模糊的原因而发生，并且无论您采用哪种方式，都值得关注。）
因此，在每次测试之前重建每个环境都是如此。 />一般值得开销。
一般情况并非总是如此。有一些配置问题是在测试开始时最好处理一次，而且一次在
结束时，这与订单完全无关<每个基本测试运行的
。
当你的客户不断询问某些东西时，你就会告诉他们他们真的不要他们要求什么？b $ b要求，谁在l，，谁在顽固？
John Roth
Python Fit。
- Bj ?? rn Lindstr ?? m< bk ** @ stp.lingfil.uu.se>
瑞典乌普萨拉大学计算语言学学生
In August 2001, there was a thread about the "Art of Unit Testing":
http://groups.google.com/group/comp....a29faf0a0485d5
Paul Moore asked the legitimate question why there is no hook for a
"global" fixture code that is run only once for the whole TestCase, as
opposed to the normal "setUp" and "tearDown" code that is run for every
single test in the TestCase. A "global fixture" would be preferable
whenever creating the fixture is time consuming, e.g. you have to create
a database connection or even a whole database.
What would be the preferred solution for such global fixtures? Simply
create the database, run the TestCase, and drop the database?
Would it make sense to add "globaleSetup" and "globalTearDown" methods
to the TestCase class? I think at least it would not harm anybody. Where
should such proposals be submitted?
-- Christoph Zwerschke
The py.test module offers setup/teardown hooks at the method, class and
module level. The scenario you''re describing would be covered at the
module level. See the py.test documentation for more details:
<http://codespeak.net/py/current/doc/test.html#managing-test-state-across-test-modules-classes-and-methods>
Grig
====
http://agiletesting.blogspot.com
Christoph Zwerschke <zw*******@zuv.uni-heidelberg.de> writes:
Would it make sense to add "globaleSetup" and "globalTearDown" methods
to the TestCase class? I think at least it would not harm
anybody. Where should such proposals be submitted?
In general that''s not such a good idea. If you build your tests like
that, it gets hard to know which test really went wrong, and you might
get the situation where the whole set of tests works, but depend on each
other in some way. (This can also happen for more obscure reasons, and
is worth looking out for whichever way you do it.)
So, rebuilding the environment for the each before every single test is
generally worth the overhead.
--
Bj??rn Lindstr??m <bk**@stp.lingfil.uu.se>
Student of computational linguistics, Uppsala University, Sweden
""Bj??rn Lindstr??m"" <bk**@stp.lingfil.uu.se> wrote in message
news:87************@lucien.dreaming...Christoph Zwerschke <zw*******@zuv.uni-heidelberg.de> writes:Would it make sense to add "globaleSetup" and "globalTearDown" methods
to the TestCase class? I think at least it would not harm
anybody. Where should such proposals be submitted?
In general that''s not such a good idea. If you build your tests like
that, it gets hard to know which test really went wrong, and you might
get the situation where the whole set of tests works, but depend on each
other in some way. (This can also happen for more obscure reasons, and
is worth looking out for whichever way you do it.)
So, rebuilding the environment for the each before every single test is
generally worth the overhead.
Generally is not always. There are configuration issues that are
best dealt with once at the beginning of the test, and once at
the end, and that have absolutely nothing to do with the order
in which each elementary test runs.
When your customers keep asking for something, and you
keep telling them that they really don''t want what they''re
asking for, who''s lisening, and who''s being stubborn?
John Roth
Python Fit.
--
Bj??rn Lindstr??m <bk**@stp.lingfil.uu.se>
Student of computational linguistics, Uppsala University, Sweden
这篇关于单元测试艺术的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
