【发布时间】：2017-01-22 12:28:17
【问题描述】：
我已经为我的项目的关键业务逻辑编写了一些单元测试，并且我了解 TDD 的概念和优缺点 - 我只是从来没有真正“一路走 TDD”，首先编写测试并且东西。我目前正在从事一个不是我自己开发的中型项目，这非常糟糕：根本没有测试，紧密耦合的架构，没有依赖注入，遗留 MVC 框架等等 - 不太理想.我正在考虑使用 Laravel 或 Symfony 从头开始，并应用 TDD 来真正实现松散耦合和可测试的代码。
我知道，对于这样一个“大型”项目，一头扎进 TDD 可能不是一个好主意，所以我想我会做几个测试项目，看看 TDD 如何影响我的代码设计和质量。为了它，让我们假设它只是某种“电影租赁应用程序”，具有用户注册和租借电影的功能（如果可用）。我们还假设我已经做了一些 UML 图，并且我对所需的对象、它们的关系和所需的业务逻辑有一些想法。
那么：从哪里开始？在与在 MVC 框架上进行 TDD 的人交谈时，有些人倾向于“隔离”业务逻辑的一个功能并从验收测试开始，该功能是“显示可用电影列表”，测试类似于“导航到/movies 并针对某些 HTML 进行断言”或其他任何内容。对我来说，这并不是一个好的开始。
就我个人而言，我喜欢从用户登录或用户管理之类的功能入手——这些功能几乎都是支持应用程序而不是业务逻辑本身。如果我使用这种方法，我会不会故意忽略我已经知道我需要的功能？让我们假设电影列表测试有效，所以我会添加另一个测试，如“OnlyLoggedInUserCanSeeMovieList”，看到它失败并将逻辑添加到代码中 - 我知道在我编写第一个测试之前我需要的逻辑。我很难相信这会带来更好的代码，因为我故意不实现我已经知道的功能。
这只是个人喜好还是有什么类似的最佳实践让我开始？你们如何在 Symfony 或 Laravel 等框架中开始使用 TDD？在这种情况下进行纯 TDD 是否还有意义，因为框架本身已经处理和测试了很多应用程序逻辑？不要误会我的意思：我不想就 TDD 的利弊展开另一场战争——我敢肯定，一旦我完全理解了这一点，我可以从中受益。尽管如此，现在这感觉像是在相当简单的功能上取得了可笑的微小进步，我觉得我最好只对应用程序逻辑的重要部分进行单元测试，而不是做所有的“写测试，看到它失败，写代码，重构”迭代。
感谢您的意见，
克里斯
【问题讨论】：
标签： php unit-testing model-view-controller tdd