PHPUnit是一个野兽。它很大，有时有点违反直觉，而且它有它的缺陷。你的代码自然会是直观的，并且完美地满足你的直接需求。我也经常思考是否编写自己的测试框架是不是向前迈出了一步，但是.... a.它不是。你可以在一天内完成一个基本的测试框架，但是：

• PHPUnit集成在大多数现代IDE中;
• PHPUnit可以很好地与XDebug一起工作，生成代码覆盖报告;
• PHPUnit可以和Selenium一起工作进行集成测试;
• PHPUnit被许多程序员使用，这意味着你的测试对他们中的许多人来说是立即清楚的;
• PHPUnit可以集成到一个CI设置中，例如Travis CI。
• PHPUnit有一个模拟库;
• 最重要的是：PHPUnit * 工作正常 *。

有很多理由反对自己写。

@hakre没有提到的两点：

代码覆盖率

对代码覆盖率（可视化执行了多少代码）进行漂亮的报告并不那么容易，即使xDebug使您能够相当快地开始工作，也有一些边缘情况和烦恼需要花费相当长的时间来构建。
PHPUnit helps you out with a nice report.

报告

测试时最重要的是能够快速找出问题所在。
为PHP中的所有内容（异常、对象、字符串、xml、json等）自己构建**a nice diff**是相当耗时的
此外，在某个时候，您可能希望移动到Jenkins这样的持续集成服务器，而PHPUnit这样的测试框架已经生成了所有需要的工件（junit.xml、clover.xml），使您能够进行set up CI for your projects in half an hour。
因此，总而言之，即使您不使用所有高级特性和助手（如模拟、测试遗留代码的进程隔离、outputBuffering、异常助手），您也会得到一个基础设置，它将能够随着您的项目的增长和成熟而增长。

仅限CLI

顺便说一句，有一个名为Visual PHPUnit的**a web interface to phpunit**可以在浏览器中运行。即便如此，老实说，我也不知道为什么有人会想要这个。也许没有刷新，但我宁愿在cli终端上运行一个脚本循环。但每个人都有自己的想法：）

我自己写剧本不是更好吗？

• • 不**，这不是一个更好的主意。如果你创建自己的脚本，你就是在独自编程。有了PHPUnit，你就有了一个庞大的用户社区，负责单元测试通常需要的各种功能，所以复制和共享代码可以减少工作量。

它是一个软件，而且只有在复制的时候才不会变坏。另外，它还带有许多输入（例如配置）和输出（测试结果格式、代码覆盖率、报告）以及集成（命令行运行程序、IDE、CI服务器...）。当你今天开始的时候，你甚至不会接近它。
但是你可以不用PHPUnit就开始测试驱动开发，然后自己编写测试，这对学习TDD很有帮助，也有助于更好地理解为什么要使用测试框架。

我想上面已经提到了，但是因为没有正确的答案，让我补充一下：不要犯行业中的经典错误，即被驱使去重新发明轮子。如果已经有一个事实上的标准，社区和/或企业支持任何一个有路线图的软件......使用它。设计自己的解决方案的唯一好处是学习如何让这些核心更好地为其他已建立的解决方案工作。所以回答你的问题，你能做到吗，是的，你应该，不，也许，这是教育。为什么使用PHP，你可以创建自己的语言。为什么使用框架X，你可以创建自己的框架。你明白的。除非你真的有一个独特的方法，清楚地证明了一个比流行的现有方法更好的产品，这是一个坏的道路，甚至想。

我能想到的使用phpunit而不是自定义测试的唯一原因是IDE的支持和它可以在一个单独的进程中运行测试的事实。当涉及到运行测试时，其他一切都可以使用自定义脚本轻松实现。
除了测试之外，phpUnit还提供了一些有用的特性，比如支持覆盖率、支持分析、支持在多个进程中运行测试、支持Xdebug。