单元测试验收测试？
我目前正在进行一些验收测试，这将有助于推动我即将要做的程序的设计。一切看起来都很好，除了我意识到验收测试有点复杂，也就是说，虽然它们在概念上很简单，但它们需要相当多棘手的代码来运行。我需要为我的验收测试制作几个“帮助”类。
我的问题是如何开发它们：
- 对我的验收测试进行单元测试（这看起来很奇怪——有人做过类似的事情吗？）
- 为那些帮助类进行单元测试。完成这些帮助类的所有代码后，我可以通过并开始进行系统的真正单元测试。使用这种方法时，您会将辅助类放在哪里？在测试项目中还是在实际项目中？它们不一定依赖于测试/模拟框架。
- 还有其他想法吗？
I am currently making some Acceptance-Tests that will help drive the design of a program I am about to do. Everything seems fine except I've realized that the Acceptance-Tests are kinda complex, that is, although they are conceptually simple, they require quite a bit of tricky code to run. I'll need to make a couple of "helper" classes for my Acceptance-Tests.
My question is in how to develop them:
- Make Unit-Tests of my Acceptance-Tests(this seems odd -- has anyone done anything like it?)
- Make Unit-Tests for those help classes. After I have done all the code of those help classes, I can pass and start working on the real Unit-Tests of my System. When using this approach, where would you put the helper classes? In the tests' project or in the real project? They don't necessarily have dependencies on testing/mocking frameworks.
- Any other idea?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
一位朋友非常热衷于这样的概念：验收测试会告诉您代码是否损坏，而单元测试会告诉您代码在哪里损坏；这些是互补且有价值的信息。验收测试可以更好地让您知道何时完成。
但要完成任务，您需要一路上的所有部分；你需要它们工作，这就是单元测试的强项。先进行测试，它们还将引导您进行更好的设计（而不仅仅是有效的代码）。一个好的方法是编写一个总体验收测试，并对自己说：“当这通过时，我就完成了。”然后努力让它通过，工作 TDD：为通过 AT 所需的下一点功能编写一个小型单元测试；编写代码使其通过；重构；重复。随着你的进步，时不时地运行 AT；你可能会发现它在测试中越来越失败。而且，如上所述，当它过去时，你就完成了。
我认为单元测试验收测试本身没有多大意义。但是对它的帮助器类进行单元测试——实际上，先测试地编写它们——是一个非常好的方法。您可能会发现您编写的一些“只是为了测试”的方法正在进入生产代码中 - 即使您没有，您仍然想知道您的 AT 使用的代码是否正常工作。
如果你的 AT 足够简单，那句老话“测试测试代码，代码测试测试”可能就足够了 - 当你的测试失败时，要么是因为代码错误，要么因为测试错误，并且应该很容易找出哪个。但当测试很复杂时，最好也对其基础进行良好的测试。
A friend is very keen on the notion that acceptance tests tell you whether your code is broken, while unit tests tell you where it's broken; these are complementary and valuable bits of information. Acceptance tests are better at letting you know when you're done.
But to get done, you need all the pieces along the way; you need them to be working, and that's what unit tests are great at. Done test-first, they'll also lead you to better design (not just code that works). A good approach is to write a big-picture acceptance test, and say to yourself: "when this is passing, I'm done." Then work to make it pass, working TDD: write a small unit test for the next little bit of functionality you need to make the AT pass; write the code to make it pass; refactor; repeat. As you progress, run the AT from time to time; you will probably find it failing later and later in the test. And, as mentioned above, when it's passing, you're done.
I don't think unit testing the acceptance test itself makes much sense. But unit testing its helper classes - indeed, writing them test-first - is a very good way to go. You're likely to find some methods that you write "just for the test" working their way into the production code - and even if you don't, you still want to know that the code your ATs use is working right.
If your AT is simple enough, the old adage of "the test tests the code, and the code tests the test" is probably sufficient - when you have a failing test, it's either because the code is wrong or because the test is wrong, and it should be easy enough to figure out which. But when the test is complicated, it's good to have its underpinnings well tested, too.
如果您将软件开发视为汽车生产厂，那么编写软件的行为就像开发一辆新车。每个组件都经过单独测试，因为它是新的。这是以前从未做过的。 （如果有，您可以找以前做过的人，也可以直接购买。）
您的构建系统，用于构建您的软件并对其进行测试，就像传送带 - 生产汽车的过程一辆车又一辆车。汽车制造商通常会考虑如何自动化生产新零部件并测试他们的汽车，作为制造新汽车的一部分，你可以打赌他们也会测试生产这些汽车的机器。
所以，是的，对你的验收测试进行单元测试对我来说似乎非常好，特别是如果它可以帮助你更快地进行并使事情更容易改变。
If you think of software development like a car production plant, then the act of writing software is like developing a new car. Each component is tested separately because it's new. It's never been done before. (If it has, you can either get people who've done it before or buy it off the shelf.)
Your build system, which builds your software and also which tests it, is like the conveyor belt - the process which churns out car after car after car. Car manufacturers usually consider how they're going to automate production of new components and test their cars as part of creating new ones, and you can bet that they also test the machines which produce those cars.
So, yes, unit-testing your acceptance tests seems perfectly fine to me, especially if it helps you go faster and keep things easier to change.
使用单元测试框架（如 JUnit）编写验收测试（或集成测试）没有任何问题。由于多种原因，人们不喜欢称它们为“单元测试”。对我来说，主要原因是集成/验收测试不会在每次检查更改时运行（太长或/并且没有适当的环境）。
您的帮助程序类是相当标准的东西，包含“测试基础设施代码”。除了测试代码之外，它们不属于其他任何地方。您可以选择测试或不测试它们。但如果没有它们，您的测试在大型系统中将不可行。
所以，你的选择是#2或者根本不进行测试。重构基础设施代码以使其更加透明和简单并没有什么错。
There is nothing wrong with using unit test framework (like JUnit) to write acceptance tests (or integration tests). People don't like calling them 'unit tests' for many reasons. To me the main reason is that integration/acceptance tests won't run every time one checks in the changes (too long or/and no proper environment).
Your helper classes are rather standard thing that comprise "test infrastructure code". They don't belong anywhere else but test code. It's your choice to test them or not. But without them your tests won't be feasible in big systems.
So, your choice is #2 or no tests of tests at all. There is nothing wrong with refactoring infrastructure code to make it more transparent and simple.
你的选项 2 是我的做法：首先编写辅助类测试 - 听起来你知道它们应该做什么。
测试就是测试，虽然辅助类不是严格的测试，但它们不会被主代码引用，而只是测试，因此它们属于测试。也许它们可以位于与常规测试不同的包/命名空间中。
Your option 2 is the way I'd do it: Write helper classes test-first - it sounds like you know what they should do.
The tests are tests, and although the helper classes are not strictly tests, they won't be referenced by your main code, just the tests, so they belong with the tests. Perhaps they could be in a separate package/namespace from regular tests.