Unit testing helps you make sure that your code is working properly but the black-box approach has its limits. In fact, in a complex program with (unsurprisingly) complex behavior, black-boxing becomes a major hindrance to testing. So what are the options? There are several options, but they all seem to have their inconveniences; some violate the basic tenets of object oriented programming, some introduce additional occasions for bugs. I think that there’s no easy solution.
Things I never, ever, want to hear. Ever.
- In theory,… No, I don’t want to know what you think the code does, I want to know that it actually does—especially if you’re the one that wrote the code. If you haven’t verified, validated by actually testing stuff in a systematic manner, you have failed. Have you validated the functions with stringent unit testing? No? then get out of my face and go write code to test your code. Validate your hypotheses. Always.
Developing software isn’t easy. No, I’m serious. It’s not. Every year that passes brings us more experience, and sometimes reality bites us real hard in the ‘rear.
For example, people do not always remain with a project until it completes. Often, people join a team for a summer, or for a year or two, then leave. That’s normal and expected. Of course, if the project is large, or the stay short, the code portion that was assigned to a particular individual may not be completed by the time he leaves. Can you manage to leave a team gracefully?