问题描述
最近我们一直在向现有的 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 验证请求并调用业务层
- 业务层通过hibernate等做了很多事情并更新了一些数据库表
- 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 请求/响应，另一端是数据库.如果这些工作正常，那么我们可以自由地重构或处理中间的任何内容，并对被测 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?
推荐答案
你问的是两种不同事物的优缺点(骑马和骑摩托车的优缺点是什么?)
You are asking pros and cons of two different things (what are the pros and cons of riding a horse vs riding a motorcycle?)
当然，两者都是自动测试"(~riding)，但这并不意味着它们是替代品(你不会骑马数百英里，也不会在封闭的环境中骑摩托车-车辆泥泞的地方)
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)
单元测试测试代码的最小单元，通常是一个方法.每个单元测试都与它正在测试的方法密切相关，如果它写得很好，它(几乎)只与它相关.
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.
它们非常适合指导新代码的设计和现有代码的重构.在系统准备好进行集成测试之前，它们很适合发现问题.请注意，我编写了 guide，所有的测试驱动开发都是关于这个词的.
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).
如果你更积极地重构，改变方法的存在或行为，那么是的，你需要为每个新方法编写一个新的单元测试，并可能丢弃旧的.但是编写单元测试，特别是如果你在代码本身之前编写它，将有助于阐明设计(即什么方法应该做什么，什么它不应该) 而不会被实现细节弄糊涂(即如何方法应该做它需要做的事情).
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).
自动化集成测试测试代码的最大单元，通常是整个应用程序.
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:
- 较小的集成测试，仅测试您要重构的部分.如果您要重构整个事情，那么您可以使用您当前的集成测试，但是如果您只是重构 - 比如说 - XML 生成，那么要求数据库的存在没有任何意义，所以我会写一个简单而小型的 XML 集成测试.
- 为您要编写的新代码提供一堆单元测试.正如我在上面已经写过的，一旦你弄乱了中间的任何东西"，单元测试就会准备好，确保你的乱七八糟"在某个地方.
实际上，您的集成测试只会确保您的混乱"不起作用(因为一开始它不会起作用，对吗?)但它不会给您任何线索
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 只会在最后给出确认(并且很长一段时间答案都是否").在重构过程中，集成测试不会给您任何帮助，这会使重构变得更加困难并且可能令人沮丧.您需要为此进行单元测试.
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.
这篇关于自动化单元测试与自动化集成测试的优缺点是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，WP2