部署伪装成程序的大型测试
如果有人创建了一个使用（单元）测试作为逻辑的小型诊断内部 Web 应用程序，那么是否有这样做的正当理由？请记住，无论该网站位于何处，都必须部署 Nunit。
我认为程序应该包含自己的逻辑和可能可重用的部分（如果可用），但不要对其逻辑进行包装测试。测试的目的是验证代码逻辑。如果您说测试将是代码逻辑，那么您是否不需要编写测试来验证测试？为什么这从根本上是错误的？
提示：因为现在您将所有这些测试串联在一起并将它们相互关联，这意味着它们不再是依赖的（？）。
If someone has created a small diagnostic, internal web app that uses (unit) tests as its logic, is there ever a valid reason to do that? Keep in mind that Nunit has to be deployed as well where ever this website goes.
I'm of the view that programs should contain their own logic and possibly reusable parts (if available) but not wrap tests for their logic. Tests serve the purpose of validation for code logic. If you than say tests are going to be code logic, shouldn't you need to write tests to validate the tests? Why is that fundamentally wrong?
Hint: Because now you are stringing all of these tests together and interrelating them, which means they are no longer dependent(?).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
使用单元测试框架进行单元测试以外的其他任务通常不是最合适的路径。您不必为单元测试编写测试，因为您首先编写它们并看到它们失败。这就是您如何知道它们工作正常的方式。我猜想在单元测试框架中编写的测试代码并不简单，如果我有一个针对关键软件的诊断应用程序，我真的很想确定它能正常工作。
编辑：看来您已经下定决心，但需要支持来表达为什么当前策略对其他项目成员来说不太理想。如果是这种情况，我建议您将代码放在您想说的地方，并拼凑一个以不同方式设计的小示例应用程序。如果在这种特定情况下使用单元测试框架是一个糟糕的设计决策，那么这就很清楚了。
Using a Unit test framework for something else than unit tests is usually not the most proper path. You don't have to write tests for your unit tests, since you write them first and see them fail. That's how you know they're working properly. I'm guessing testing code written within a unit test framework is nontrivial, and if I had a diagnostics app for a critical piece of software, I would really like to be certain it worked as it should.
Edit: It seems that you've already made up your mind but need support in expressing why the current strategy is less than ideal to, perhaps, other project members. If that's the case, I suggest you put your code where your mouth is, and throw together a small sample app designed differently. If utilizing a unit test framework in this specific case was a bad design decision, then that would make it clear as sunshine.
我很确定如果您查看这个问题 TDD Anti-patters Catalogue，您会发现你正在犯下严重的反模式。
I'm pretty sure if you look at this question TDD Anti-patters catalogue, you will find that you are commiting sever anti-patterns.
代码就是代码。仅仅因为它被标记为测试并不意味着它不是一个有用的应用程序。
假设我们需要编写大量的行为验证。为什么使用测试框架是一个坏主意？我们是否应该编写一个具有相同功能的新框架并命名为不同的名称？
从外部看。该应用程序声称可以执行某些操作。它做得正确吗？可靠吗？能否维持、增强？明白了吗？
如果是这样，为什么你关心它在实现中碰巧使用了测试框架呢？如果它的行为或结构有缺陷那么我们就会批评。
伟大技术的一个可爱之处在于它有意想不到的应用。
Code is code. Just because it's labeled a test doesn't mean it's not also a useful application.
Suppose we need to write a lot of verifications of beahviour. Why is using test framework a bad idea? SHoudl we instead write a new framework with identical function and call it something different?
Take an external view. This applciation claims to do certain things. Does it do them correctly? reliably? Can it be maintained, enhanced? Understood?
If so, why do you care that it happens to use a test framework in its implementation. If its behaviour or structure are defective then we criticise.
One lovely thing about great technology is that it has unexpected applications.
单元测试的目的是确保您的类按照其应有的方式并根据接口工作。因此，如果您将单元测试用于某些测试应用程序，则似乎在程序逻辑中使用断言。
如果您需要一些测试应用程序 - 实现它并与单元测试一起使用。它可能是为了配置某些东西或获得一些用户交互。
我看到的其他原因之一 - 单元测试是根据一切如何工作的假设编写的。如果您的假设正确，测试应该通过。添加功能时，单元测试让您确信所有假设仍然存在。因此，每个测试都应该尽可能简单。这就是为什么不需要测试测试代码，也不需要在任何测试应用程序中使用测试代码。
The purpose of unit testing is to make sure your class works the way it should and according to the interface. So if you are using your unit tests for some testing app it seems like using assert in programm logic.
If you need some testing app - implement it and use WITH unit tests. It maybe to configure something or to get some user interaction.
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.