PHP：使用MVC应用程序的测试驱动开发

我已经在为我的项目的关键业务逻辑编写一些单元测试，我知道TDD的概念和优缺点——我只是从来没有真正“一路TDD”先编写测试之类的东西。我目前正在做一个中型项目，我没有自己开发，这是非常可怕的工作：根本没有测试，紧密耦合的体系结构，没有依赖注入，遗留的MVC框架，等等-不太理想。我正在考虑从零开始使用Laravel或Symfony并应用TDD来真正实现松散耦合和可测试的代码

我知道，对于这样一个“大型”项目，直接深入TDD可能不是一个好主意，所以我想我应该做几个测试项目，看看TDD如何影响我的代码设计和质量。鉴于此，我们假设它只是一种“电影租赁应用程序”，具有用户注册和一个租赁电影（如果可用）的功能。我们还假设我已经做了一些UML图，并且对所需的对象、它们的关系和所需的业务逻辑有了一些想法

那么：从哪里开始呢？当与在MVC框架上进行TDD的人交谈时，有些人倾向于“隔离”业务逻辑的功能，并开始接受测试，该功能是“显示可用电影列表”，测试类似于“导航到/movies并根据一些HTML断言”或其他内容。对我来说，这不是一个好的开始

就我个人而言，我喜欢从用户登录或用户管理等功能开始，这些功能相当于支持应用程序，而不是业务逻辑本身。如果我使用这种方法，我会故意忽略我已经知道需要的函数吗？让我们假设电影列表测试有效，所以我会添加另一个测试，如“OnlyLoggedInUserCanSeeMovieList”，看到它失败，然后将逻辑添加到代码中——我知道在编写第一个测试之前就需要这种逻辑。我发现很难相信这会带来更好的代码，因为我故意不实现我已经知道的功能

这仅仅是个人喜好，还是有什么最佳实践可以让我开始？你们是如何在Symfony或Laravel这样的框架中开始使用TDD的？在这种情况下，考虑到大量应用程序逻辑已经由框架本身处理和测试，纯TDD有什么意义吗？别误会我的意思：我不想再就TDD的利弊展开另一场战争——我确信，一旦我完全明白了这一点，我可以从中受益。尽管如此，现在在相当简单的功能上，这感觉像是一个荒谬的微小进步，我觉得我最好只是对应用程序逻辑的重要部分进行单元测试，而不是进行所有的“写测试，看到它失败，写代码，重构”迭代

谢谢你的意见

---

Chris

我想说的是，首先你需要做一些研究，以找到你将要使用的捆绑包。例如，你说你宁愿开始单元测试你的用户管理，除了在fSymfony中，你已经有了很好的用户管理捆绑包，它们已经随测试系列一起提供了。 因此，我想说，开始你的项目的第一步是找到已经存在并符合你需要的东西。在抽象出尽可能多的内容之后，应该更容易了解从何处开始（通常编写测试以确保您使用的所有捆绑包都能正常工作）

希望这能帮助你开始