单元测试艺术

本文介绍了单元测试艺术的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！ 问题描述 限时删除！！ 2001年8月，有一个关于单位测试艺术的帖子： http://groups.google.com/group/comp....a29faf0a0485d5 保罗·摩尔问了一个合理的问题，为什么没有任何关于全球的问题。整个TestCase仅运行一次的fixture代码，因为 与普通的setUp相反和tearDown在TestCase中为每个 单个测试运行的代码。 全局固定装置在创建灯具时耗时很长，例如。你必须创建一个数据库连接甚至是整个数据库。 这些全球设备的首选解决方案是什么？只需 创建数据库，运行TestCase，然后删除数据库？ 添加globaleSetup是否有意义和globalTearDown方法 到TestCase类？我认为至少它不会伤害任何人。 应该提交这样的提案吗？ - Christoph Zwerschke 解决方案 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....a29faf0a0485d5Paul Moore asked the legitimate question why there is no hook for a"global" fixture code that is run only once for the whole TestCase, asopposed to the normal "setUp" and "tearDown" code that is run for everysingle test in the TestCase. A "global fixture" would be preferablewhenever creating the fixture is time consuming, e.g. you have to createa database connection or even a whole database.What would be the preferred solution for such global fixtures? Simplycreate the database, run the TestCase, and drop the database?Would it make sense to add "globaleSetup" and "globalTearDown" methodsto the TestCase class? I think at least it would not harm anybody. Whereshould such proposals be submitted?-- Christoph Zwerschke 解决方案 The py.test module offers setup/teardown hooks at the method, class andmodule level. The scenario you''re describing would be covered at themodule 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 likethat, it gets hard to know which test really went wrong, and you mightget the situation where the whole set of tests works, but depend on eachother in some way. (This can also happen for more obscure reasons, andis worth looking out for whichever way you do it.)So, rebuilding the environment for the each before every single test isgenerally 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 messagenews: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 arebest dealt with once at the beginning of the test, and once atthe end, and that have absolutely nothing to do with the orderin which each elementary test runs.When your customers keep asking for something, and youkeep telling them that they really don''t want what they''reasking for, who''s lisening, and who''s being stubborn?John RothPython Fit. -- Bj??rn Lindstr??m <bk**@stp.lingfil.uu.se> Student of computational linguistics, Uppsala University, Sweden 这篇关于单元测试艺术的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！ 1403页，肝出来的..