BDD、单元测试和设计模式
我编写了一个标准化 USPS 地址的方法 。为了测试它，我希望第 45 行的 open(URI.encode(uri)) 返回一个模拟、指定的响应，以防您未连接到互联网等。我该怎么做与 Rspec?我需要将该方法分成两个吗？
我不愿意将方法分解成多个部分，除非我重用这些部分。如果我只使用它一次，我就把它放入函数中。这样，我就避免了额外的函数调用（因为额外的函数调用不是效率更低吗？）。这是一个坏主意吗？
有时，代码项目有如此多不同的类和函数，并且如此模块化和抽象，这使得我理解起来更加复杂。我必须跳到不同的功能。也许我应该将 vim 与 ctags 一起使用。
但是，如果您不打算重用不同的部分，为什么要分解功能呢？
我还没有读过设计模式，但我正在读Cocoa 设计模式这本书。
谢谢！
马特
I wrote a method to standardize a USPS address. To test it, I want open(URI.encode(uri)) on line 45 to return a mock, specified response in case you're not connected to the Internet, etc. How do I do this with Rspec? Do I need to break up the method into two?
I am averse to breaking up methods into parts unless I am reusing these parts. If I'm just using it once, I'll just put it into the function. That way, I avoid the extra function call (cause aren't extra function calls more inefficient?). Is this a bad idea?
Sometimes code projects have so many different classes and functions and are so modularized and abstract, that it makes it more complicated for me to figure out. I have to jump around to different functions. Maybe I should use vim with ctags.
But why break up functions if you're not going to be reusing the different parts?
I haven't read Design Patterns yet, but I'm reading the book Cocoa Design Patterns.
Thanks!
Matt
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
为了清晰起见，便于测试。
相反的顺序：如果你有一个由两部分组成的函数，并且它被破坏了，你不知道哪一部分被破坏了。如果您已经分解（并测试）了这些部件，您就会知道其中哪一个损坏了（或者两个都坏了；如果没有对非常小的功能进行非常小的测试，这些可能是最难找出的错误）。当您开始谈论的不是两部分函数，而是二十或五十部分函数时，这一点变得更加正确。
关于清晰度，您说过，对于您来说，代码更难遵循，更难弄清楚，因为有更多的类和方法。我们中的许多人发现事实恰恰相反。一个微小的函数很容易理解。如果它的命名很好，那么另一个函数对它的使用也很容易理解——并且比内联更容易理解。抽象对于优秀的软件工程至关重要；学会爱它。
For clarity, for ease of testing.
In reverse order: If you have a two-part function, and it's broken, you don't know which part is broken. If you have broken out (and tested) the parts, you will know which of them is broken (or that both of them are; these can be some of the hardest bugs to figure out without very small tests of very small functions). This becomes more true when you start talking, not about two-part functions, but about twenty- or fifty-part functions.
With respect to clarity, you've said that for you code is harder to follow, harder to figure out, with more classes and methods. Many of us find the contrary to be true. A tiny function is easy to understand. If it is well named, its use by another function is also easy to understand - and easier to understand than if it were inlined. Abstraction is critical to good software engineering; learn to love it.