Jan 28, 2005 / Are Unit Tests Always Useful?
2 commentsI think they aren't.
Unit tests help me to think about what I want exactly from a method (for example). But there are times when I know what method should return me, but very aproximately. For example, there are several acceptable results, but I just do not know what is the best in my case. Unit test will not solve this problem. Even more, if I choose one way from start and create unit test, I may miss a better way, so unit test may suppress my creativity.
This may sounds strange, but think a bit about this. A possible solution in this case is prototyping. Try several approaches without unit tests and the choose the most appropriate. Any other ideas?
UPDATED Jan 28:
I really do write tests first, but sometimes I wonder if this is always good for system architecture. Well, in most cases it is. The basic flow is like that: 1. write a code (for example, controller). And just realize that existing API is insufficient. 2. think a bit about possible extension and make a decision 3. write a test for this new desired method. 4. write a code for this test. 5. review the code and refactor on a "lower level" (rename, extract method, ...) 6. after awhile, review API and refactor on a higher level (new interfaces, classes) I don't think that this process really suppresses my creativity. Refactoring is a key. Discussion about this topic at Artima
posted by Michael Dubakov @ 7:32 AM
2 Comments:
I often write several tests each of which tries different things. Using unit tests allows me to prototype (play around) with only small part of the application and any changes can be quickly seen. Often unit tests evolve together with the code when I'm working on something new. I would think usage of unit tests is a matter of personal opinion, and everybody will have a different view on the matter.
"Even more, if I choose one way from start and create unit test, I may miss a better way, so unit test may suppress my creativity."
I'd say that if your unit tests are restricting your creativity (eg, restricting your ability to have flexible adaptable design), then your tests suck and should be written in such a way as to not restrict your creativity.
Rigid tests are just as bad as rigid code. They suck.
Post a Comment
<< Home