【问题标题】:Deploying a big test disguised as a program部署伪装成程序的大型测试
【发布时间】:2009-08-19 14:21:13
【问题描述】:

如果有人创建了一个使用(单元)测试作为其逻辑的小型诊断内部 Web 应用程序,那么是否有这样做的正当理由?请记住,Nunit 也必须部署在该网站所在的任何位置。

我认为程序应该包含它们自己的逻辑和可能的可重用部分(如果有的话),但不能为它们的逻辑包装测试。测试的目的是验证代码逻辑。如果您说测试将成为代码逻辑,那么您是否不需要编写测试来验证测试?为什么这从根本上是错误的?

提示:因为现在您将所有这些测试串在一起并相互关联,这意味着它们不再相互依赖(?)。

【问题讨论】:

  • 然后你会测试测试的测试吗?如果你这样想,有点失控......
  • 所依赖的 NUnit 依赖项是什么?
  • 因为调用的是测试程序集,需要Nunit,所以项目必须部署Nunit。该应用程序在测试程序集中使用 [Test] 来做一些工作。换句话说,那些测试将东西留在数据库中,然后这个应用程序会使用这些东西。我认为这相当混乱。
  • 诊断应用程序使用数据库是否合法,也许是为了记录其结果?你反对它使用数据库吗?还是这个特定的数据库?
  • 对上述问题: 1.) 是的。 2.) 没有和没有。我反对将正式测试包装到其业务逻辑中的应用程序。这不是测试的目的。

标签: unit-testing design-patterns testing methodology software-quality


【解决方案1】:

将单元测试框架用于单元测试以外的其他事情通常不是最合适的方法。您不必为单元测试编写测试,因为您先编写它们并看到它们失败。这就是你如何知道他们工作正常。我猜测在单元测试框架中编写的测试代码是不平凡的,如果我有一个用于关键软件的诊断应用程序,我真的很想确定它是否可以正常工作。

编辑:您似乎已经下定决心,但需要支持来表达当前策略对其他项目成员可能不太理想的原因。如果是这样的话,我建议你把你的代码放在嘴边,然后把一个设计不同的小示例应用程序放在一起。如果在这种特定情况下使用单元测试框架是一个糟糕的设计决策,那么这将使它变得清晰起来。

【讨论】:

  • 谁说测试本身没有经过测试?
  • 我从“如果您说测试将是代码逻辑,您不需要编写测试来验证测试吗?”,我得到的印象是测试没有经过测试。
  • Eclipse 源代码的 Manuel wolker 不久前有一篇关于测试以及如何测试测试的博文。他的观点是代码测试测试,测试测试代码。 eclipsesource.com/blogs/2009/02/17/unit-testing-revelations
  • 我在一定程度上同意(见我上面的回答)。但是,如果您有一个诊断应用程序,例如,它通过访问 url 检查 web 应用程序是否启动,那么仅仅运行诊断应用程序并不意味着它已经过测试,因为实际上有两种可能的预期结果,只有一个正在测试。
  • 我的观点是我们有一个诊断应用程序。这是一个应用程序。我们可以像其他任何东西一样测试它。事实上,它本身可能包含测试,这与我们选择对应用程序本身进行多少测试无关。
【解决方案2】:

我很确定如果你看这个问题TDD Anti-patters catalogue,你会发现你正在提交服务器反模式。

【讨论】:

  • 哪些?我没有看到任何证据(还)。
  • 简单的选择是您使用单元测试来运行快乐路径而不是测试。另一个是给出问题标题的巨人。而且我无法判断这是单个测试还是多个测试,但是如果将测试用作实际逻辑,则您可能使用的是背驮式或链式帮派。通过您的cmets,我认为我可能已经将其拉长了一点,但这不是故意的。对我来说,使用测试作为生产代码的想法很糟糕。
  • 就我所见,这些模式都是关于如何组织测试并确保 tehir 完整性的。这里没有证据表明这些特定的测试会受到影响。我同意有些东西“闻起来”不太对劲,但我希望能详细说明为什么。到目前为止,这些论点并没有让我相信这个案例做错了什么。
【解决方案3】:

代码就是代码。仅仅因为它被标记为测试并不意味着它不是一个有用的应用程序。

假设我们需要编写大量的行为验证。为什么使用测试框架是个坏主意?我们是否应该编写一个具有相同功能的新框架并称之为不同的东西?

采取外部观点。这个应用程序声称可以做某些事情。它做对了吗?可靠吗?它可以维护,增强吗?明白了吗?

如果是这样,您为什么关心它在实现中碰巧使用了测试框架。如果它的行为或结构有缺陷那么我们批评。

伟大技术的一个可爱之处在于它有意想不到的应用。

【讨论】:

    【解决方案4】:

    单元测试的目的是确保您的类按照应有的方式并根据接口工作。因此,如果您将单元测试用于某些测试应用程序,则似乎在程序逻辑中使用断言。

    如果您需要一些测试应用 - 实现它并使用 WITH 单元测试。它可能是为了配置某些东西或获得一些用户交互。

    我看到的其他原因之一 - 单元测试是根据对一切工作方式的假设编写的。如果你的假设是正确的,测试应该通过。添加功能单元测试时,让您确信所有假设仍然存在。因此,每个测试都应该尽可能简单。这就是为什么不需要测试测试代码,也不需要在任何测试应用程序中使用测试代码。

    【讨论】:

      猜你喜欢
      • 2017-02-25
      • 1970-01-01
      • 2015-05-07
      • 2018-04-11
      • 2023-03-18
      • 2013-03-27
      • 2012-10-25
      • 1970-01-01
      相关资源
      最近更新 更多