因此，我正在尝试将自己转变为一种更受测试和行为驱动的开发方法。这对我有好处，到目前为止，我在使用它的几个项目中都看到了很好的结果。
我目前的项目是一个基于 FUSE 的文件系统——我想在基本文件系统访问上添加一些功能，所以 FUSE 看起来很合适。我真正需要做的就是实现一组适合适当接口的函数，适当地包装它，然后继续。
但是，先测试，我提醒自己。我已经编写了一组黄瓜特性来列出整个应用程序应该如何工作的基本期望，所以现在是时候开始测试内部结构了。
现在，我可以为需要为接口编写的每个函数编写单元测试，然后开始编写接口编码——但这对我来说似乎并没有过度测试驱动。当然测试存在，但界面才是真正的驱动力。
我要解决这个问题了吗？还是我期望太高？
如果您认为这应该是社区 wiki，请在评论中给我一个“what-what”——我什至无法确定这是否有正确的答案。
第 1 步：接口必须做的一件事是什么？一件事。
第 2 步：你将如何证明它确实做到了这一点？
步骤 3. 编写一个测试来证明接口确实做了一件事。
步骤 4. 运行测试——它会失败。您实际上还没有编写界面。
步骤 5. 对接口进行编码。
步骤 6. 测试将通过。
继续界面必须做的下一件事。
这与您已经设计的功能关系不大。这完全专注于界面必须具有的外部可见功能。事实证明，您的功能是正确的。或者结果可能是您过度设计了这些功能。或者他们的设计不足。关键是要从组件必须做的事情和测试来证明它必须做的事情来推动您的设计。
即使它只关注 Ruby，rspec 书对 BDD 循环也有很好的介绍。
我想在基本文件系统访问上添加一些功能，所以 FUSE 看起来很合适
熔断器fs很难开发。两个主要问题是非常困难的调试和多线程。我也有（现在有）测试我的 fs 的问题。也许inotify会满足您的要求。