我的上一个博客是有关测试代码方法的一系列博客中的第一篇，概述了使用一种非常常见的模式从数据库检索地址的简单方案：
…并描述了一种非常通用的测试技术：不编写测试，而是手动进行所有操作。
今天的博客涵盖了另一种实践，我也认为这是次优的。 在这种情况下，开发人员使用JUnit编写测试，但是在完成编写代码之后并且没有任何类隔离的情况下编写测试。 这实际上是冒充单元测试的“端到端”（又称集成）测试。
尽管昨天我说过我只测试AddressService类，但是使用此技术的测试首先从数据库中加载一些测试数据，然后抓住AddressController来调用被测方法。AddressController调用AddressService，然后再调用AddressDao以获取并返回所请求的数据。
@RunWith(UnitilsJUnit4TestClassRunner.class)@SpringApplicationContext("servlet-context.xml")@Transactional(TransactionMode.DISABLED)public class EndToEndAddressServiceTest {@SpringBeanByTypeprivate AddressController instance;/*** Test method for* {@link com.captaindebug.address.AddressService#findAddress(int)}.*/@Testpublic void testFindAddressWithNoAddress() {final int id = 10;BindingAwareModelMap model = new BindingAwareModelMap();String result = instance.findAddress(id, model);assertEquals("address-display", result);Address resultAddress = (Address) model.get("address");assertEquals(Address.INVALID_ADDRESS, resultAddress);}/*** Test method for* {@link com.captaindebug.address.AddressService#findAddress(int)}.*/@Test@DataSet("FindAddress.xml")public void testFindAddress() {final int id = 1;Address expected = new Address(id, "15 My Street", "My Town","POSTCODE", "My Country");BindingAwareModelMap model = new BindingAwareModelMap();String result = instance.findAddress(id, model);assertEquals("address-display", result);Address resultAddress = (Address) model.get("address");assertEquals(expected.getId(), resultAddress.getId());assertEquals(expected.getStreet(), resultAddress.getStreet());assertEquals(expected.getTown(), resultAddress.getTown());assertEquals(expected.getPostCode(), resultAddress.getPostCode());assertEquals(expected.getCountry(), resultAddress.getCountry());}}
上面的代码使用Unitils将测试数据加载到数据库中并在Spring上下文中加载类。 我发现Nevers是一个有用的工具，它消除了编写此类测试的繁琐工作，而必须设置如此大规模的测试是一项艰巨的工作。
这种测试必须在代码完成后编写； 它不是测试驱动的开发（从以前的博客中可以看到，我是一个忠实的拥护者），它也不是单元测试。 在代码后编写测试的问题之一是必须执行测试的开发人员将其视为琐事而不是开发的一部分，这意味着它通常很匆忙，而不是在编码风格的整洁中完成的。
您还需要一定数量的基础结构才能使用此技术进行编码，因为需要建立数据库，而数据库可能会或可能不在您的本地计算机上，因此您可能必须连接到网络才能运行测试。 测试数据要么保存在测试文件中（如本例所示），然后在运行测试时加载到数据库中，要么永久保存在数据库中。 如果需求变更迫使测试发生变更，则通常需要将数据库文件与测试代码一起进行更新，这迫使您至少在两个位置更新测试。
除了缺乏测试对象隔离之外，这种测试的另一个大问题是它们可能非常慢，有时要花几秒钟来执行。 Shane Warden在他的《敏捷开发的艺术》一书中指出，单元测试的运行速度应为“每秒数百”。 沃登还继续引用迈克尔·费瑟（Michael Feather）的书《有效地使用旧版代码》，以明确定义什么单元测试或不可以：
在以下情况下，测试不是单元测试：
它与数据库对话。 它通过网络进行通信。 它涉及文件系统。 您必须对环境做一些特殊的事情（例如编辑配置文件）才能运行它。
…现在我喜欢。
…尽管我不一定同意第三点。 良好的单元测试代码的主要租户之一是可读性。 传递给被测对象的方法参数有时会很大，尤其是在使用XML时。 在这种情况下，我认为支持测试的可读性并将这种大小的数据存储在数据文件中而不是将其作为私有的静态最终String更为实用，因此在可行的情况下，我只坚持第3点。
可以使用第一个首字母缩写来总结单元测试：快速，独立，可重复，自我验证和及时，而Roy Osherove在他的《单元测试的艺术》一书中总结了一个很好的单元测试：“自动代码调用方法或类，然后检查有关该方法或类的逻辑行为的一些假设。 单元测试几乎总是使用单元测试框架编写的。 它可以轻松编写并快速运行。 它是完全自动化的，可信赖的，可读的和可维护的”。
端到端测试的好处是，他们确实会与其他对象和周围环境一起测试您的测试主题，而这在交付代码之前确实是必须要做的。 这意味着完成后，您的代码应包含数百个单元测试，但仅包含数十个“端到端”测试。
鉴于此，当我说技术是“次优”时，我的介绍性前提并不严格。 “端到端”测试没有任何问题，每个项目都应该有一些测试以及一些普通的集成测试，但是这类测试不能替代或称为单元测试，通常是这种情况。
确定了单元测试的内容后，我的下一个博客将调查您应测试的内容以及原因……
参考：Captain Debug博客上的 JCG合作伙伴 Roger Hughes的“ 端到端测试的滥用-测试技术2”
相关文章 ：
测试技巧–不编写测试 您应该对什么进行单元测试？ –测试技术3 常规单元测试和存根–测试技术4 使用模拟的单元测试–测试技术5 为旧版代码创建存根–测试技术6 有关为旧版代码创建存根的更多信息–测试技术7 为什么要编写单元测试–测试技巧8 一些定义–测试技术9 使用FindBugs产生更少的错误代码 在云中开发和测试
翻译自: //11/misuse-of-end-to-end-tests-testing.html
