什么是自动单元测试VS自动化集成测试的利弊？ [英] What are the pros and cons of automated Unit Tests vs automated Integration tests?
问题描述
最近我们一直在增加自动测试，以我们现有的Java应用程序。
Recently we have been adding automated tests to our existing java applications.
我们有什么
多数这些测试都是集成测试，可以覆盖这样的方法调用堆栈： -
The majority of these tests are integration tests, which may cover a stack of calls like:-
- HTTP后成servlet
- 该servlet验证请求并调用业务层
- 业务层通过休眠等做了一堆东西，并更新一些数据库表
- 该servlet产生一些XML，运行此通过XSLT生成HTML的响应。
我们然后验证的servlet报以正确的XML和在数据库中存在的正确行（我们的开发Oracle实例）。然后，这些行被删除。
We then verify that the servlet responded with the correct XML and that the correct rows exist in the database (our development Oracle instance). These rows are then deleted.
我们也有一些小的单元测试，检查单的方法调用。
We also have a few smaller unit tests which check single method calls.
这些测试都运行作为我们的夜间（或即席）的一部分的基础之上。
These tests are all run as part of our nightly (or adhoc) builds.
问题
这是因为我们正在检查我们的制度的界限似乎不错。如果这些工作，那么我们可以自由地重构或任何其间的混乱，并有一定的信心所测试的servlet的继续工作。
This seems good because we are checking the boundaries of our system: servlet request/response on one end and database on the other. If these work, then we are free to refactor or mess with anything inbetween and have some confidence that the servlet under test continues to work.
什么问题，我们可能碰上这种做法？
What problems are we likely to run into with this approach?
我看不出加入一些个人类的更多的单元测试将帮助。这难道不使其难以重构，因为它是更容易，我们需要扔掉，重新写测试？
I can't see how adding a bunch more unit tests on individual classes would help. Wouldn't that make it harder to refactor as it's much more likely we will need to throw away and re-write tests?
推荐答案
您问的两回事利弊（哪些优点和骑马VS骑摩托车的利弊？）
You are asking pros and cons of two different things (what are the pros and cons of riding a horse vs riding a motorcycle?)
当然都是自动测试（〜骑），但是，这并不意味着他们是替代（你不骑马数百英里，而且你不封闭骑摩托车 - 车辆泥泞的地方）
Of course both are "automated tests" (~riding) but that doesn't mean that they are alternative (you don't ride a horse for hundreds of miles, and you don't ride a motorcycle in closed-to-vehicle muddy places)
单元测试测试code的最小单位，通常的方法。每个单元测试是紧密联系在一起的，它正在测试的方法，如果它写得好它的捆绑（几乎）只有这一点。
Unit Tests test the smallest unit of the code, usually a method. Each unit test is closely tied to the method it is testing, and if it's well written it's tied (almost) only with that.
他们都是伟大引导的设计的新的code和的重构的现有code的。他们都是伟大的长发现问题之前，系统准备集成测试。请注意，我写的指导的和所有的测试驱动开发是关于这个词。
They are great to guide the design of new code and the refactoring of existing code. They are great to spot problems long before the system is ready for integration tests. Note that I wrote guide and all the Test Driven Development is about this word.
它没有任何意义，有手动的单元测试。
It does not make any sense to have manual Unit Tests.
有关重构，这似乎是你的主要关注什么？如果您在重构的方法只是实现（内容），但没有它的存在和外在行为，单元测试仍然是有效的和非常有用的（你无法想象有多少有用的，直到你试试）。
What about refactoring, which seems to be your main concern? If you are refactoring just the implementation (content) of a method, but not its existence or "external behavior", the Unit Test is still valid and incredibly useful (you cannot imagine how much useful until you try).
如果您正在重构更积极，改变方法存在或行为，那么，你需要编写为每个新的方法新的单元测试，并可能扔掉旧的。可是我在写单元测试，特别是如果你的code本身之前写出来，将有助于澄清设计（即 的方法应该做的事情，和什么它不应该）未经执行细节混淆（即的方法应该如何做的事，它需要做的）。
If you are refactoring more aggressively, changing methods existence or behavior, then yes, you need to write a new Unit Test for each new method, and possibly throw away the old one. But writing the Unit Test, especially if you write it before the code itself, will help to clarify the design (i.e. what the method should do, and what it shouldn't) without being confused by the implementation details (i.e. how the method should do the thing that it needs to do).
自动化集成测试测试code最大的单位，通常整个应用程序。
Automated Integration Tests test the biggest unit of the code, usually the entire application.
他们都是伟大测试的您不想手动测试使用案例的。但你也可以有手动集成测试，它们都是同样有效（只不太方便）。
They are great to test use cases which you don't want to test by hand. But you can also have manual Integration Tests, and they are as effective (only less convenient).
从今天开始一个新项目，它没有任何意义不要有单元测试，但我要说，对于像你这样一个现有的项目它没有太大的意义给他们写的一切你已经有了，它是工作。
Starting a new project today, it does not make any sense not to have Unit Tests, but I'd say that for an existing project like yours it does not make too much sense to write them for everything you already have and it's working.
在你的情况，我宁愿使用中间地带的方式写：
In your case, I'd rather use a "middle ground" approach writing:
- 较小的集成测试，只有测试你要重构部分。如果您在重构整个事情，那么你可以使用当前的集成测试，但如果你只重构的-say- XML生成，它没有任何意义，要求数据库的presence，所以我d写一个简单的小XML集成测试。
- 为新的code你打算写一堆单元测试的。正如我上面已经写了，单元测试，只要你有任何之间大锅饭做好准备，确保你的大锅饭是去什么地方。
在事实上你集成测试只会确保你的烂摊子不工作（因为它不会工作的开始，对吧？），但它不会给你的。
In fact your Integration Test will only make sure that your "mess" is not working (because at the beginning it will not work, right?) but it will not give you any clue on
- 为什么它不工作
- 如果您的烂摊子的调试真正固定的东西
- 如果您的烂摊子的调试别的东西破
集成测试只会给确认在最后，如果整个变化是成功的（和答案是不很长一段时间）。集成测试不会给你重构本身，这将使它更难，可能令人沮丧的过程中的任何帮助。你需要单元测试的。
Integration Tests will only give the confirmation at the end if the whole change was successful (and the answer will be "no" for a long time). The Integration Tests will not give you any help during the refactoring itself, which will make it harder and possibly frustrating. You need Unit Tests for that.
这篇关于什么是自动单元测试VS自动化集成测试的利弊？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
