I totally agree with you, David! <br><br>For quite a while I was testing all my methods (even had to declare them protected/package scope in java!), but I realized that I was getting into a lot of trouble. Now I've shifted to testing functionality in stead of methods.
<br><br>Now, sometimes you might end up having small methods (typically a result of refactoring) that are being used by several clients. In that case you should start testing those methods, since they actually represent real business logic.
<br>I talked to uncle Bob about this issue just a few months ago, and as far as I understood, he uses a similar approach.<br><br>I think it might make sense to think of the facade pattern when you do your testing - do you really care what happens behind the facade?
<br><br>Stefan<br><br><div><span class="gmail_quote">2008/1/9, David Chelimsky <<a href="mailto:dchelimsky@gmail.com">dchelimsky@gmail.com</a>>:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Jan 8, 2008 1:25 PM, Matt Patterson <<a href="mailto:matt-lists@reprocessed.org">matt-lists@reprocessed.org</a>> wrote:<br><br>You should check out the bowling kata<br>(<a href="http://butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata">
http://butunclebob.com/ArticleS.UncleBob.TheBowlingGameKata</a>) if you<br>haven't. At the end there are just a few tests and they all touch only<br>2 public methods, but there are many, many smaller methods that appear
<br>through refactoring. They are all thoroughly tested, though not<br>directly.<br><br>Cheers,<br>David<br>______________</blockquote></div><br>-- <br>Bekk Open Source<br><a href="http://boss.bekk.no">http://boss.bekk.no
</a>