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

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



On 17 March 2014 18:55, Herman Peeren <> wrote:
> Developers don't use the private method in their
> extensions. I'd be very intersted in counter-examples; they are probably an
> indication of a problem.

That's exactly right. Public is for direct usage. Protected is where
you want to allow the developer user to override some functionality.
Private is for functionality that you do not want the user developer
to touch. However, private code still needs to be tested "somehow".

Lest say you have a public function `Foo` and a private function `Bar`.

`Foo` obviously needs a test designed to isolate the code it runs.
However, `Foo` calls `Bar`. The question is not "do I test `Bar` but
"how do I test `Bar`. There are three ways.

1. Write a unit test just for the `Bar` method. If the method returns
a specific value, I'd suggest write a unit test. Or,

2. Just write the test for `Foo` and in the DocBlock note that you are
covering `Bar`, that is:

* @covers Foo
* @covers Bar

If you do that, the code coverage report is going to show you whether
you are covering the code in the `Bar` method.

3. Ignore code coverage of `Bar` completely and just trust that
testing `Foo` covers all the possible scenarios in order to detect a
regression.

Ultimately, what strategy you take will probably depend on the usage
but I don't agree with the assertion that "private" === "no need to
test". Let's take an example:

https://github.com/joomla-framework/string/blob/master/src/Inflector.php#L159

This is private method. There is no way of knowing whether it's
working or not by using the public API, see:
https://github.com/joomla-framework/string/blob/master/src/Inflector.php#L382

If there is a bug in the private method such that it always returns
false, then the code will still run. However, performance will
degrade. In this case, it is appropriate to write a unit test
specifically for the private method. It also ensures that anyone
trying to <cough>improve</cough> the internal cache doesn't stuff it
up in spectacular fashion.

Let's take a second example
https://github.com/joomla-framework/cache/blob/master/src/File.php#L205

It returns true or throws an exception so chances are it either works
or fails dramatically. In this case I would be happy for the tests of
`__construct` or `fetchStreamUri` to cover it, but since two methods
use it, it's probably worth writing a single unit test because a
refactor might in the future might change when the private API is
called.

The bottom line is you need to eye-ball the code and anticipate what
can go wrong, and things go wrong in private methods as much as they
do in protected or public. I'd err on the side of "if in doubt, write
a test" because when we deal with many contributors over long periods
of time, people can forget why things were or weren't done. And let's
face it, some people that wrote a lot of code are no longer around to
catch us from falling.

Herman, I hope that makes the position clear. If you do have something
to contribute and it does contain private methods, we can look at the
tests on the merit of the specific case.

Regards,
Andrew Eddie

-- 
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.