读完这篇帖子后，我感觉和这个人处于同样的位置谁问了这个问题。我热爱技术，想出新的想法来解决现实世界的问题只会让我的神经元兴奋，但等式的另一部分——实际上（快速）完成事情——通常是一件很痛苦的事，特别是当我“我这样做是为了我自己。
有时我对代码感到有点无聊，有时我会花更多时间在文本编辑器中移动光标并盯着我的代码，试图想出一个比我已有的解决方案更好的解决方案。我听说这是一种完美主义病。
我在同一篇文章中读过（也在这里读过几次），TDD 实际上很好地阻止 像女孩一样编码，但是我从来没有给过 TDD 机会 - 要么是因为我懒得学习/设置它，要么是因为我认为我不需要因为我可以在脑海中完成我需要的所有测试。
- 您是否也相信 TDD 实际上有助于 GTD？
- 关于 TDD 我需要了解什么？
- TDD 的替代品怎么样？
- 组织/开发 TDD Web 应用程序的最佳方法是什么？
- 我应该使用哪些库（如果有）来让我的生活更轻松？
PS：我在这里主要（但不完全）使用 PHP。
After reading this post I kinda felt in the same position as the guy who asked the question. I love technology and coming up with new ideas to solve real world problems just gets my neurons horny, but the other part of the equation - actually getting things done (fast) - is normally a pain in the ass to accomplish, specially when I'm doing this for myself.
Sometimes I kinda feel plain bored with code, some other times I spend more time moving the cursor in the text editor and staring at my code, trying to come up with a solution that is better than the one I already have. I heard this is a disease called perfectionism.
I've read in that same post (and also a few times here on SO too) that TDD is actually good to stop coding like a girl, however I've never given a chance at TDD - either because I'm too lazy to learn / set it up or because I don't think I need it because I can do all the tests I need inside my head.
- Do you also believe that TDD actually helps to GTD?
- What do I need to know about TDD?
- What about alternatives to TDD?
- What would be the best methodology to organize / develop a TDD web app?
- What libraries should I use (if any) to make my life easier?
PS: I'm primarily (but not exclusively) working with PHP here.
发布评论
评论（3）
就我个人而言，我认为 TDD 往好了说是矫枉过正，往坏了说是编程创造性过程的障碍。为每个尚未编写的方法/类费力地编写单元测试的时间最好花在解决原始问题上。话虽这么说，我是单元测试的忠实粉丝，并且全心全意地相信它们。如果我有一段特别复杂或麻烦的代码，我非常乐意为单个方法编写 20 个单元测试，但通常是在解决问题之后。 TDD 与其他所有编程范式一样，并不是灵丹妙药。如果适合你就使用它，如果不适合继续寻找。
但请对我的观点持保留态度。更有趣的一个来自 Kent Beck 和 您的单元测试有多深？。
Personally I think TDD is at best overkill and at worst an impediment to a the creative process of programming. Time that is spent laboriously writing unit tests for each as yet unwritten methods/classes would be better spent solving the original problem. That being said I am a big fan of unit tests and believe wholeheartedly in them. If I have a particularly complex or troublesome piece of code I'm more than happy to write 20 unit tests for a single method but generally AFTER I have solved the problem. TDD, just like every other programming paradigm, is no silver bullet. If is suits you use it if not keep looking.
But take my opinion with a grain of salt. A much more interesting one comes from Kent Beck and How deep are your unit tests?.
您是否也相信 TDD 实际上有助于 GTD？
我最大的担忧就是无法测试代码。太复杂了。我们的核心库并不是围绕易于测试的界面构建的。所以我们尽我们所能编写测试。最后，我们重构了我们的核心库，让生活变得更轻松。除此之外，这是思维方式的改变，我肯定会考虑在您的第一个 TDD 项目上分配更多时间，只是为了解决您在此过程中可能遇到的一些问题。
关于 TDD 我需要了解什么？
TDD 不能替代方法论。这是一个有益的补充，或者至少应该是。如果做得好，TDD 可以极大地改进软件设计。它还可以作为您的内部文档。如果您希望有人查看您的 API 并了解其工作原理，他们只需查看您命名良好的成型测试即可。
TDD 的替代品怎么样？
就像我说的，我不会认为这是方法论的替代品。还有一种替代方案，那就是不使用它:)
组织/开发 TDD Web 应用程序的最佳方法是什么？
如果您问的是的话，我们在 Scrum/Agile 方面已经相当成功了。
我应该使用哪些库（如果有）来让我的生活更轻松？
我的 PHP 知识已经过期 5 年前了，我会让其他人来回答这个问题。
不管怎样，只要我的2分钱。如果您觉得阅读这里是一个很好的概述：http://www.agiledata.org/essays /tdd.html
Do you also believe that TDD actually helps to GTD?
My biggest concern was simply not being able to test code. It was too complex. Our core libraries weren't built around an easily testable interface. So we wrote tests for whatever we could. In the end we ended up refactoring our core libraries to make life easier. Besides that, it's a change of a mindset, and i would definitely consider allocating more time on your first TDD project just to kind of flush out some of the problems you may have along the way.
What do I need to know about TDD?
TDD is not a substitute for a methodology. It is a beneficial addition or at least it's supposed to be. If done right, TDD greatly improves software design. It also acts as your internal documentation. If you want somebody to look at your API and understand how it works they can simply look at your well named an formed tests.
What about alternatives to TDD?
Like i said, i wouldn't consider this a substitute for a methodology. There is an alternative and that is not to use it :)
What would be the best methodology to organize / develop a TDD web app?
We have been fairly successful with scrum/agile, if that's what you're asking.
What libraries should I use (if any) to make my life easier?
My PHP knowledge has expired 5 years ago, and i'll let somebody else answer this.
Either way, just my 2 cents. If you feel like reading here is a good overview: http://www.agiledata.org/essays/tdd.html
我最近开始使用“胖模型瘦控制器”http://www. amitshah.in/php/controller-vs-model.html ：将尽可能多的代码放入模型中（并从视图/控制器中取出）。
我使用 PHPUnit（以及对其的 Zend Framework 支持）仅测试 Web 应用程序中的一些复杂模型。恕我直言，编写单元测试来彻底检查执行简单 SQL 查询的 2 行函数是浪费时间。在过去的几年里，我在编写测试方面变得越来越懒，对于大多数网络应用程序来说，这是不值得的，因为代码非常简单。
但在最近的一个项目（一个跟踪复合产品多个仓库的库存水平的电子商务网站）中，我开始进行测试优先开发，因为我知道将会有很多微妙的复杂性，我无法全部记住立刻。随着我的思维发展，让一切正常运转的唯一方法就是编写一些测试。对于某些部分，编写类然后编写测试似乎更自然，其他部分首先进行测试，而其他部分则不需要测试，因为它们很琐碎。 TDD 是一种工具，而不是一种宗教。有用就用，没用就停止。
我认为 TDD 的好处在于降低复杂性并提高速度（解决问题的速度）。如果我编写一些测试来证明我的代码可以正常工作，那么一旦所有测试通过，我就可以继续处理下一个问题。这让我重新找回了编码的乐趣。
I've recently started using "fat models thin controllers" http://www.amitshah.in/php/controller-vs-model.html : shovelling as much code into the model (and out of the view / controller) as possible.
I use PHPUnit (and the Zend Framework support for it) to test only a few complex models in my web apps. Writing unit tests that exhaustively check a 2 line function that executes a simple SQL query is a waste of time IMHO. Over the last couple of years I've got lazier and lazier with writing tests, and for most web apps its not worth it because the code is so simple.
But in a recent project (an ecommerce site that tracks stock levels over multiple warehouses with composite products) I started doing test-first development because I knew there was going to be a lot of subtle complexity that I couldn't keep in my head all at once. The only way to keep everything working as my thinking developed was to write some tests. With some parts it seemed more natural to write the class then the tests, other parts were test first, yet other parts didn't need tests because they were trivial. TDD is a tool, not a religion. Use it when it works, stop if it doesn't.
Where I see the benefit in TDD is in reducing complexity and increasing speed (the rate at which I can solve problems). If I write some tests that prove my code is working, then as soon as the all the tests pass, I can move on to the next problem. This puts the fun back in coding for me.