python - TDD - 初学者问题和绊脚石

Question

虽然我已经为我所做的大部分代码编写了单元测试，但我最近才通过 Kent Beck 的示例获得了一份 TDD 副本。我一直对我做出的某些设计决定感到遗憾，因为它们阻止了应用程序“可测试”。我通读了这本书，虽然其中一些看起来很陌生，但我觉得我可以管理它并决定在我当前的项目中尝试它，该项目基本上是一个客户端/服务器系统，两个部分通过该系统进行通信。 USB。一个在小工具上，另一个在主机上。该应用程序使用 Python。

我开始了，很快就陷入了困惑的重写和小测试中，后来我发现这些并没有真正测试任何东西。我把它们中的大部分都扔掉了，现在有了一个工作应用程序，它的测试全部凝结成 2 个。

根据我的经验，我有几个问题想问。我从 New to TDD: Are there sample applications with tests to show how to do TDD? 获得了一些信息但有一些具体的问题我想回答/讨论。

1. Kent Beck 使用他添加和删除的列表来指导开发过程。你如何制作这样的 list ？我最初有一些项目，如“服务器应该启动”，“如果 channel 不可用，服务器应该中止”等，但它们混合在一起，最后现在，它就像“客户端应该能够连接到服务器”(其中包含服务器启动等)。
2. 您如何处理重写？我最初选择了基于命名管道的半双工系统，以便我可以在自己的机器上开发应用程序逻辑，然后添加USB通信部分。他们变成了基于套接字的东西，然后从使用原始套接字转移到使用 Python SocketServer 模块。每次事情发生变化时，我发现我不得不重写相当一部分测试，这很烦人。我认为在我的开发过程中，测试将是一个不变的指南。他们只是觉得需要处理更多的代码。
3. 我需要一个客户端和一个服务器通过 channel 进行通信以测试任一方。我可以模拟其中一方来测试另一方，但是整个 channel 都不会被测试，我担心我会错过。这有损于整个红/绿/重构节奏。这只是缺乏经验还是我做错了什么？
4. “假装直到成功”给我留下了很多乱七八糟的代码，后来我花了很多时间重构和清理这些代码。事情就是这样运作的吗？
5. 在 session 结束时，我的客户端和服务器现在运行了大约 3 或 4 个单元测试。我花了大约一周的时间才完成。如果我在代码后使用单元测试，我想我可以在一天内完成。我看不到 yield 。

我正在寻找使用这种方法完全(或几乎完全)实现大型非平凡项目的人的评论和建议。 在我已经运行了一些东西并想添加一个新功能，但从头开始做这件事似乎很累，而且不值得付出努力，这对我来说是有意义的。

附注: 请让我知道这是否应该是社区 wiki，我会这样标记它。

更新 0 :所有答案都同样有帮助。我选择了我做的那个，因为它最能与我的经历产生共鸣。

更新 1:练习练习练习!

Answer 1

作为初步评论，TDD 需要练习。当我回顾我开始 TDD 时编写的测试时，我发现了很多问题，就像我查看几年前编写的代码时一样。继续这样做，就像您开始识别好代码和坏代码一样，您的测试也会发生同样的事情 - 要有耐心。

How do you make such a list? I initially had a few items like "server should start up", "server should abort if channel is not available" etc. but they got mixed and finally now, it's just something like "client should be able to connect to server"

“列表”可能相当不正式(贝克的书中就是这种情况)，但是当您开始将项目纳入测试时，请尝试将语句写成“[当发生某些事情时] 那么 [这个条件应该是真的]”格式。这将迫使您更多地考虑您正在验证的是什么，您将如何验证它并直接转化为测试 - 或者如果没有，它应该为您提供有关缺少哪个功能的线索。考虑用例/场景。例如，“服务器应该启动”不清楚，因为没有人在启动操作。

Each time things changed, I found that I had to rewrite considerable parts of the tests which was annoying. I'd figured that the tests would be a somewhat invariable guide during my development. They just felt like more code to handle.

首先，是的，测试包含更多代码，并且需要维护 - 编写可维护的测试需要练习。我同意 S. Lott 的观点，如果您需要大量更改测试，那么您可能测试“太深”了。理想情况下，您希望在不太可能更改的公共(public)接口(interface)级别进行测试，而不是在可能演变的实现细节级别进行测试。但是练习的一部分是关于提出一个设计，所以你应该预料到其中的一些错误，并且还必须移动/重构你的测试。

I could mock one of the sides to test the other but then the whole channel wouldn't be tested and I worry that I'd miss that.

不完全确定那个。从它的声音来看，使用模拟是正确的想法:选择一侧，模拟另一侧，并检查每一侧是否工作，假设另一侧已正确实现。一起测试整个系统是集成测试，您也想这样做，但通常不是 TDD 流程的一部分。

The "Fake it till you make it" left me with a lot of messy code that I later spent a lot of time to refactor and clean up. Is this the way things work?

在进行 TDD 时，您应该花费大量时间进行重构。另一方面，当你伪造它时，它是暂时的，你的下一步应该是取消伪造它。通常你不应该因为你伪造它而通过多个测试 - 你应该一次专注于一个，并尽快重构它。

I think I could have done it in a day if I were using the unit tests after code way. I fail to see the gain.

同样，这需要练习，随着时间的推移，你应该会变得更快。另外，有时候TDD比其他的更有成效，我发现在某些情况下，当我确切地知道我要写的代码时，写好部分代码然后写测试会更快。
除了 Beck，我喜欢的一本书是 Roy Osherove 的 The Art of Unit Testing。这不是一本 TDD 书，它是面向 .Net 的，但无论如何你可能都想看看它:一个很好的部分是关于如何编写可维护的测试、测试质量和相关问题。我发现这本书在我进行了书面测试后与我的经历产生了共鸣，有时我很难做到正确......
所以我的建议是，不要把毛巾扔得太快，给它一些时间。您可能还想尝试一些更简单的事情 - 测试与服务器通信相关的事情听起来并不是最容易开始的项目!