我已经观看并阅读了一些关于 PHPUnit 和测试驱动开发的教程，并且最近开始使用 Laravel，它使用它的 TestCase 类扩展了 PHPUnit 框架。就在开发过程中创建测试而言，所有这些对我来说都是有意义的。而且我发现 Laravel 的扩展特别直观（尤其是在测试控制器路由方面）
但是，我最近的任务是为一个已接近完成的大型应用程序创建单元测试。该应用程序是在 Codeigniter 中构建的，它没有经过任何测试
我发现我不完全确定从哪里开始，或者要采取什么步骤来确定我应该创建的测试。
我应该测试每个控制器方法吗？还是我需要更多地分解它？诚然，这些控制器方法中的许多都在做不止一项任务。
【问题讨论】：
标签： codeigniter unit-testing tdd phpunit
为现有项目编写测试真的很困难。我建议您首先为不依赖于其他类的类编写测试。然后，您可以继续为与您编写测试的类耦合的类编写测试。您将通过重复此过程逐步增加测试覆盖率。
也不要忘记，有时您需要重构代码以使其可测试。您应该改进代码设计，例如，如果您的控制器方法执行多个任务，您应该将此方法划分为子方法并独立测试这些方法中的每一个。
我也建议你看看这个question
【讨论】：
你的处境有点紧张，但这是我在你的情况下会做的事情。您需要重构（即更改）现有代码，以便最终获得三种类型的函数。
第一类是与外界打交道的。我的意思是任何与 I/O、框架或操作系统甚至库或来自稳定模块的代码对话的东西。基本上所有依赖于你不能或可能不会改变的代码的东西。
第二组函数是您转换或创建数据结构的地方。他们唯一应该知道的是他们作为参数接收的数据结构，而他们返回的唯一方式是更改这些结构或创建和填充新结构。
第三组由协调函数组成，它们调用外部函数，获取它们返回的数据结构并将这些结构传递给转换函数。
您的测试策略如下：可以通过创建假数据结构、将它们传入并检查转换是否正确完成来测试第二组。第三组协调函数可以通过依赖注入和模拟来测试，看看它们是否正确地调用了外部世界和转换函数。最后，不应测试最后一组功能。你遵循格言 - “让它变得如此简单，以至于他们显然没有错”。看看您是否可以将其保留在一行代码中。如果你为这些代码写了四行代码，那么你可能做错了。
如果您对 TDD 完全陌生，但我强烈建议您首先习惯在新领域项目/模块上进行操作。我在单元测试上做了几个错误的开始，因为我后来试图将它固定到项目中。当你最终摸索到 TDD 时，它真的是一种乐趣，所以如果你因为太陡峭的学习曲线而早早泄气，那就不好了。
【讨论】：