In a case where I know that I'm doing things I shouldn't within tests (eg: periodically I'll peek into my objects innards to ensure what's supposed to be there is there, and that a getter is in fact looking at the right thing) and am about to make a change that I know will break numerous tests, I assess at a high-level which tests I expect to break, fix them one at a time, ensuring that each fix is the correct one, and I'm not changing something that broke unexpectedly.
I would rather update 30 tests across 10 files in these types of cases than not have enough tests to tell me that I've broken something that will be found later.
Another benefit of writing tests I find, is that it allows me to understand the philosophy of design decisions in ways I may not have thought of originally, due to the nature of throwing crap at things. Sometimes in early stages of a new project, my tests will dictate that the API needs modifications. Not only that, but I often don't write example scripts to test my code; I just begin each sub by starting a new test file for it (typically). That's usually my example script.
In reply to Re^7: To parens or not parens in chained method calls
by stevieb
in thread To parens or not parens in chained method calls
by stevieb
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |