如果有人创建了一个使用（单元）测试作为其逻辑的小型诊断内部 Web 应用程序，那么是否有这样做的正当理由？请记住，Nunit 也必须部署在该网站所在的任何位置。
我认为程序应该包含它们自己的逻辑和可能可重用的部分（如果有的话），但不能为它们的逻辑包装测试。测试的目的是验证代码逻辑。如果您说测试将成为代码逻辑，那么您是否不需要编写测试来验证测试？为什么这从根本上是错误的？
提示：因为现在你将所有这些测试串在一起并相互关联，这意味着它们不再依赖（？）。
问问题
166 次
4 回答
3
将单元测试框架用于除单元测试之外的东西通常不是最合适的路径。您不必为单元测试编写测试，因为您先编写它们并看到它们失败。这就是你知道他们工作正常的方式。我猜测在单元测试框架中编写的测试代码是不平凡的，如果我有一个用于关键软件的诊断应用程序，我真的很想确定它可以正常工作。
编辑：您似乎已经下定决心，但需要支持来表达为什么当前策略对其他项目成员不太理想。如果是这样的话，我建议你把你的代码放在嘴边，然后把一个设计不同的小示例应用程序放在一起。如果在这种特定情况下使用单元测试框架是一个糟糕的设计决策，那么这将使它变得清晰起来。
于 2009-08-19T14:34:37.657 回答
0
代码就是代码。仅仅因为它被标记为测试并不意味着它不是一个有用的应用程序。
假设我们需要写很多beahviour的验证。为什么使用测试框架是个坏主意？我们是否应该编写一个具有相同功能的新框架并将其称为不同的东西？
采取外部观点。这个应用程序声称可以做某些事情。它做对了吗？可靠吗？它可以维护，增强吗？明白了吗？
如果是这样，您为什么关心它在实现中碰巧使用了测试框架。如果它的行为或结构有缺陷，那么我们就会批评。
伟大技术的一个可爱之处在于它有意想不到的应用。
于 2009-08-19T14:24:33.447 回答
0
我很确定如果您查看这个问题TDD Anti-patters catalog，您会发现您正在提交服务器反模式。
于 2009-08-19T14:28:14.377 回答
0
单元测试的目的是确保您的类按照应有的方式并根据接口工作。因此，如果您将单元测试用于某些测试应用程序，则似乎在程序逻辑中使用断言。
如果您需要一些测试应用程序 - 实现它并使用 WITH 单元测试。它可能是为了配置某些东西或获得一些用户交互。
One of the other reasons I see - unit test are written according to assumptions on how everything works. If your assumption is right tests should pass. When adding functionality unit tests let you feel confident that all assumptions are still there. So every test should be kept as simple as you can keep it. that`s why no need to test test code and no need to use testing code in any testing applications.
于 2009-08-23T17:15:01.603 回答