[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[jfw] Re: Private methods should not be unit-tested
On Saturday, 15 March 2014 03:11:30 UTC+1, garyamort wrote:
Secondly, there are spec/documentation tests. For a lot of code, it's not always clear just what you expect some bit of code to return. A good example of this is in the Registry class. I was working on extending the class with some additional functionality for a specific purpose. Here I /need/ to know what some of these private methods are expected to return so I can decide whether to use/extend them or not. So as I went through the documentation, I'd add a unit test to make sure the code matched the documentation - and fixed the documentation when it did not[and then submitted pull requests].
Basically, whenever you are adding documentation and you write "to use X do this" - you should write a unit a test for that and provide linkage to the documentation. Otherwise you end up with docs that don't get updated when code was updated.
In that way, using unit tests as documentation, you end up changing the tests when changing the code; I'd prefer the other way around. If you want to document a private method, wouldn't it be better to put the specs in the docblock? And of course the docblock should be updated whenever the interface changes. That is then immediately seen in an automatically generated API-specification. Much more useful than changing the tests.
You hit an important point however: what is the API? We have had some discussion about that recently. Developers also use private methods of a class when extending from it. And so, in a way, the private methods also become part of the interface, at least for developers. And because a lot of code has been written already, using those private methods, we should not change them (and consequently they can just as well be unit-tested). When writing code that can be extended by other developers we are making the base code very rigid. Interesting: this is exactly the discussion we had some time ago about specifying an API for Joomla. That becomes more clear in this light. Thanks.
I personally try to use object-composition over inheritance as much as possible. In that way, even as a developer you don't use private methods of other objects. Probably the overuse of private methods of objects you have not made yourself is an indication of an architectural weakness.
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.