[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [jfw] Re: Private methods should not be unit-tested



On Sunday, 16 March 2014 15:35:05 UTC+1, Don Gilbert wrote:
>What you're saying (and please correct me if I'm wrong) is that tests should exercise the public interface of a class so that further down the line, any given implementation can be tested using the tests written for the original implementation. If the new implementation passes those tests, then it is a viable alternative implementation to the existing code. 

Yes. I just wonder if it is worth publishing tests for implementations. If that implementation is using other building blocks, then those blocks have interfaces too and the test should be at that building-block-class. Sandi's presentation is very clear; you'll like it.

This is not meant as a rant and I know that in the current codebase of Joomla it won't have much consequenses, but I'm trying to think a bit more about why we are testing and what should be tested. Especially after seeing Sandi's presentation I came to the conclusion we are often testing too much, which might even become contra-productive. In "The Art of Unit Testing" by Roy Osherove (Manning Publications, second edition, 2014) there is an interesting section (8.1.1): "Deciding when to remove or change tests".

First it was necessary to see why tests are useful, but a next step might be why some tests (or at least: publishing them) might be a less good idea.


On Sunday, 16 March 2014 15:35:05 UTC+1, Don Gilbert wrote:
Herman,

I can see now where the resistance to "throwing away" the tests on private methods comes from, and I think it's because you are speaking of a fundamentally different approach to testing than what I've personally been exposed to. 

With regard to unit testing, I've always though that you must test every non-trivial unit of code to ensure that it does what you expect it to do. This is why I (and I believe others) feel that testing private and protected methods is a worthwhile exercise. 

What you're describing is a bit different than that, but I still believe you are correct. What you're saying (and please correct me if I'm wrong) is that tests should exercise the public interface of a class so that further down the line, any given implementation can be tested using the tests written for the original implementation. If the new implementation passes those tests, then it is a viable alternative implementation to the existing code. 

With that being the case, testing the private methods of a particular implementation and requiring those same tests to pass on subsequent implementations greatly reduces the flexibility of the code, making it harder to refactor and update. This gets to the heart of the matter and would explain why you (and the writer you quoted) said to mark such tests as "delete this test if it fails". 

I can see this as a much better approach to testing because it allows for more flexible code and easier refactoring, which is one of the reasons tests exist in the first place. Additionally, it makes you think about the code more, instead of blindly following the 100% Code Coverage mantra. 

Lots of thinking to do now. Thanks for bringing this up. :)

--
Framework source code: https://github.com/joomla/joomla-framework
Visit http://developer.joomla.org for more information about developing with Joomla!
---
You received this message because you are subscribed to the Google Groups "Joomla! Framework Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email to joomla-dev-framework+unsubscribe AT googlegroups.com.
Visit this group at http://groups.google.com/group/joomla-dev-framework.