单元测试

在这篇文章里，我将论述一种单元测试的新方法，让类处于测试中心。讨论一个开源工程（TestedBy），它提供一些从类开始的测试工具。

这篇文章的主旨是在正式进行单元测试之前帮助大家厘清一些概念。了解什么是单元测试，可以做什么，有哪些指导原则。做了又有什么好处，它又存在什么样的局限性。最后重点讲了现在做单元测试的难点。事实上这是任何单元测试都会面临的一个问题。在这里分享我的观点，与大家共勉！

本节是单元测试系列的第二篇。重点讲解如何使用Mock/Stub和依赖注入技术进行单元测试。关于工具JUnit等则不做累赘介绍。希望通过本章能够帮助大家开始单元测试的有益实践，与大家共勉！

接口依赖是最重要的一点，因为这可以使得我们很容易的针对一个接口实现Mock对象，模拟/替换实际对象会变的很容易。达到使一个被测对象处于一个孤立环境的测试要求。

所谓的测试，是一种产品质量保证的手段。我按照需求规格说明书制造了一件产品，那么谁来确保这个产品符合了需求规格的要求呢？就是测试。它会根据需求规格说明书设计一系列的场景和用例，来对产品进行测试，看看产品是不是真的符合所期望的需求。

目前junit测试为接口中的方法。根据javadoc中的文字说明编写junit测试方法。

软件工程中有很多新的工具，但我们往往发现叫好不叫座，而原因往往也是使用中国的一句古话就是：具体问题具体分析。但是回过头来分析一下，其实很多具体问题都是可以有办法解决的。将这些总结贡献出来，希望我们中国的软件技术走得更快点。

本文为作者在使用Junit做单元测试时测试计划中的一部分，在这里共享出来，希望大家多指教。

总的来说，还是不推荐将测试粒度放得太粗，因为这将失去单元测试的一个很大方面的作用，增加DEBUG的工作量。但是同样不应该将粒度做得太细，这样测试就没有意义了。

在实际开发过程中，我发现在单元测试代码中经常会出现两种情况：第一种就是在测试代码中炫耀编程技巧，第二种就是敷衍了事，你不是让我通过测试么？好，我就写一个用例，一定能通过的那种，然后告诉你，OK，我的测试通过了。我觉得，这就是对单元测试的意义没有真正理解的表现。

描述了单元测试要避免的几个问题，并给出几个最佳实践建议。

本文仅提供了public 方法的测试说明。及前期工作和常用的断言和测试attribute。

随着部门人数的激增，基础研发和基础平台的应运而生。对我们的挑战则是持续集成测试。

对异常的验证是单元测试中一个很重要的环节。是不是程序在测试过程中抛出异常，就是bug呢。恰恰相反，在该抛出异常的地方，一定要抛异常，如果没有抛，反而是bug。

测试中有一个pareto的原则，想必大家都知道，就是在需求和设计的静态测试中，可以发现80%的bug，但这是一个理想的状态。又有多少公司能够做到全面的需求和设计的静态测试呢，所以有很多公司会把一部分的精力放在单元测试里面，来进一步的靠近pareto的原则，一般来说，单元测试会详细描述，单元模块的划分，以及该模块的接口描述和说明。下面我来贴出来一段详细设计里面所设计到的模块的说明，我想对于有的看不到详细设计的测试工程师会有所帮助！

是在编写一个方法之前就编写它的单元测试，还是在写完这个方法，甚至是整个类之后才编写单元测试呢？John Ferguson Smart[1]在他的blog中再次提出了这个问题，并根据自己的经验给出了一些建议

在“Ode To Code“网站上，K Scott Allen理性地分析了如何在单元测试中使用mock对象，并分享了他针对mock对象框架使用情况的想法。

测试驱动开发在减少开发努力的同时也改进了软件的开发质量。单元测试，作为一整套测试策略的基础，必须是全面的，且要求易于建立和执行迅速。然而，对执行环境和被测试类外部代码的依赖性使我们实现这些目标变得更为复杂。例如，把应用程序发布到容器将显著地延长代码和测试的周期；而对其它类的依赖性通常也会导致测试的建立更加复杂和测试运行速度更为缓慢。

在极限编程中，程序员负责自己的单元测试。那么留给测试员的是什么工作呢？有人认为XP的成本比较低是因为省下了测试员的费用。那么由程序员测试就不需要测试员了吗？他们能真正替代测试员的工作吗？

测试驱动的开发和单元测试是确保代码在经过修改和重大调整之后依然能如我们期望的一样工作的最新方法。在本文中，您将学习到如何在模块、数据库和用户界面（UI）层对自己的 PHP 代码进行单元测试。