BDD, unit testing, and design patterns

I wrote a method to standardize a USPS address. To test it, I want 开发者_StackOverflowopen(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

---

why break up functions if you're not going to be reusing the different parts?

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.