我看到很多问题都在问“如何”用一种特定的语言进行单元测试,但没有人问“什么”、“为什么”和“什么时候”。
是什么? 它对我有什么用? 我为什么要用它? 什么时候用(什么时候不用)? 有哪些常见的陷阱和误解
我看到很多问题都在问“如何”用一种特定的语言进行单元测试,但没有人问“什么”、“为什么”和“什么时候”。
是什么? 它对我有什么用? 我为什么要用它? 什么时候用(什么时候不用)? 有哪些常见的陷阱和误解
当前回答
我不反对丹的观点(尽管不回答可能是更好的选择)……但是……
单元测试是编写代码来测试系统的行为和功能的过程。
显然,测试可以提高代码的质量,但这只是单元测试的表面好处。真正的好处是:
Make it easier to change the technical implementation while making sure you don't change the behavior (refactoring). Properly unit tested code can be aggressively refactored/cleaned up with little chance of breaking anything without noticing it. Give developers confidence when adding behavior or making fixes. Document your code Indicate areas of your code that are tightly coupled. It's hard to unit test code that's tightly coupled Provide a means to use your API and look for difficulties early on Indicates methods and classes that aren't very cohesive
你应该进行单元测试,因为向客户交付可维护的高质量产品符合你的利益。
我建议您将它用于任何系统,或系统的一部分,以模拟真实世界的行为。换句话说,它特别适合于企业开发。我不会将它用于一次性/实用程序。我不会用它来测试系统中有问题的部分(UI是一个常见的例子,但并不总是这样)
最大的陷阱是开发人员测试太大的单元,或者他们认为一个方法是一个单元。如果您不理解控制反转,这一点尤其正确——在这种情况下,您的单元测试总是会变成端到端集成测试。单元测试应该测试单个行为——大多数方法都有许多行为。
最大的误解是程序员不应该测试。只有糟糕或懒惰的程序员才会相信这一点。给你盖屋顶的人不应该测试吗?更换心脏瓣膜的医生不应该检查新瓣膜吗?只有程序员才能测试他的代码是否按照他的意图去做(QA可以测试边缘情况——当代码被告知要做程序员不打算做的事情时,它的行为如何,而客户可以进行验收测试——代码是否按照客户的要求去做)
其他回答
单元测试是在不需要该代码单元所依赖的基础设施的情况下对代码单元(例如单个函数)进行测试。即在隔离环境中进行测试。
例如,如果您正在测试的函数连接到数据库并执行更新,那么在单元测试中您可能不想执行该更新。如果这是一个积分测试,你会这样做,但在这个例子中,它不是。
因此,单元测试将测试您正在测试的“函数”中所包含的功能,而不会产生数据库更新的副作用。
假设函数从数据库中检索了一些数字,然后执行标准偏差计算。你想测试什么?标准偏差计算正确,还是数据从数据库返回?
在单元测试中,您只想测试标准偏差的计算是否正确。在集成测试中,您希望测试标准偏差计算和数据库检索。
单元测试是一种实践,以确保您将要实现的功能或模块的行为符合预期(需求),并确保它在边界条件和无效输入等场景下的行为。
xUnit, NUnit, mbUnit等都是帮助你编写测试的工具。
我想推荐Gerard Meszaros的《xUnit测试模式》一书。它很大,但在单元测试方面是一个很好的资源。这里有一个链接到他的网站,在那里他讨论了单元测试的基础知识。http://xunitpatterns.com/XUnitBasics.html
I think the point that you don't understand is that unit testing frameworks like NUnit (and the like) will help you in automating small to medium-sized tests. Usually you can run the tests in a GUI (that's the case with NUnit, for instance) by simply clicking a button and then - hopefully - see the progress bar stay green. If it turns red, the framework shows you which test failed and what exactly went wrong. In a normal unit test, you often use assertions, e.g. Assert.AreEqual(expectedValue, actualValue, "some description") - so if the two values are unequal you will see an error saying "some description: expected <expectedValue> but was <actualValue>".
总之,单元测试将使测试更快,对开发人员来说更舒服。您可以在提交新代码之前运行所有的单元测试,这样就不会中断同一项目中其他开发人员的构建过程。
This is my take on it. I would say unit testing is the practice of writing software tests to verify that your real software does what it is meant to. This started with jUnit in the Java world and has become a best practice in PHP as well with SimpleTest and phpUnit. It's a core practice of Extreme Programming and helps you to be sure that your software still works as intended after editing. If you have sufficient test coverage, you can do major refactoring, bug fixing or add features rapidly with much less fear of introducing other problems.
当所有单元测试都能自动运行时,这是最有效的。
单元测试通常与OO开发相关联。基本思想是创建一个脚本,为你的代码设置环境,然后练习它;您编写断言,指定您应该接收的预期输出,然后使用如上所述的框架执行您的测试脚本。
框架将针对您的代码运行所有测试,然后报告每个测试的成功或失败。phpUnit默认情况下从Linux命令行运行,尽管有HTTP接口可用于它。SimpleTest本质上是基于web的,在我看来,它更容易启动和运行。结合xDebug, phpUnit可以为您提供代码覆盖率的自动统计数据,有些人认为这非常有用。
有些团队从他们的subversion存储库编写钩子,以便在提交更改时自动运行单元测试。
将单元测试保存在与应用程序相同的存储库中是一个很好的实践。