Re: Two Critical Tips for Unit Testing in Java
Posted: Feb 15, 2003 1:51 PM
> When you write unit tests, sometimes you feel compelled
> to change your code just to facilitate the test, usually
> when you need to test a private method or attribute. Doing
> so is a bad idea. If you ever feel tempted to make a
> private method public purely for testing purposes, don't
> do it. Testing is meant to improve the quality of your
> code, not decrease it.
I agree with the point, but would love to see more in depth explanation of why its converse ia a bad idea. I think the piece is from a breezy advice column, and is excellent as such, but the topic deserves much deeper consideration and investigation. The person who follows this bit of advice without knowing why he should is just following directions and missing out on the bigger picture.
> Having said that, sometimes designing your system in a way
> that makes testing easier is still necessary. If you need
> to add a design element to support testing, ensure that it
> also increases the general quality of the system as a
> whole. If the design element doesn't, then you're
> designing your system only to facilitate testing -- which
> I must stress again is a bad idea.
> What do you think of the author's comments?
In the JUnit yahoo group recently we've been discussing the topics of testability and what it is that TDD does to ensure it without intentionally being too concerned about it.
I've tried to capture some of the underlying phenomena in my blog and posts to the yahoo group:
There are those who point to motherboard, electronics, and other manufacturing and engineering examples where test points, jumpers, and leads may be exposed to aid testability. So why should software be different? But my concern is with coming up with the best design.
There probably is no one best design for many problems -- i.e., two or more completely different implementations might be just as testable, maintainable, minimal, modular, and fast. What we have so far in software design are a lot of patterns, idioms, best practices, general recommendations and tips, i.e., practical knowledge. I think we need a better understanding of the general principles of good object oriented design, i.e., the theory underlying the practice. I think Robert Martin's recent book (Agile Software Development: Principles, Patterns and Practices) and his papers are the closest thing we have right now to a solid set of first principles.
But generally, I think it's good that practice precedes theory (just as nature precedes science). We have plenty of computer science theory, but most software design and development gets done on the job. Hopefully by investigating the principles underlying good practices we can better understand what practices, methodologies and tools work best and why.