[Mono-list] Mono test suite

[Rich Dougherty]

> | Should I test protected as well as public methods?  (e.g. by deriving a
> | front-end class from the class I am testing and allowing my test class to
> | call the protected methods).
> |
> 
> I believe, in general, only the public methods (and properties) need be
> tested with unit tests.
> 
> First of all, to test the non-public ones would require access to them. And
> they are, by definition, not accessible by the unit test because they are
> not public. You would end up adding "for testing only" public methods to get
> at them, which just ends up cluttering the sources.  Or you might do as you
> suggest and subclass to get at it.  Both of these things just don't "feel
> right".
> 
> Secondly, the public interface of a class tends to be less volatile.  It
> changes less often, in other words.  This makes it easier to keep your tests
> up to date.
> 
> Also, non-public methods will be used by the public ones eventually, and
> therefore will be tested, albeit somewhat indirectly. Those that are never
> reached by a public access point are unneeded anyway.
> 
> See http://c2.com/cgi/wiki?UnitTests for more info (and debate).  Search for
> "private implementation" on the page and read from there.


Hi

It's good to finally make a post, after lurking for so long. :-)

Are you asking about classes which are part of the .NET framework, or
are you asking about classes which are internal to Mono? In both cases
all non-private members form part of a class' interface and should
probably be tested.

However, I think it is more important to test protected members of the
.NET framework. When Mono is released, developers are going to be using
this code. It may seem a bit strange writing subclasses in tests. But
consider that this is exactly how developers will be using the Mono
code. They are going to be writing subclasses, so it makes sense to do
the same in testing.

The point about testing private methods is a good one. It is a tricky
issue when you want to write a test for a complicated piece of private
code. In the past I've found that this is an indicator that the code in
the private should be made simpler, possibly in more than one class
(that's option 2 on the page you link to). Each of these classes can
then be tested through its non-private methods. Of course, you may not
have this option with private methods in classes that form part of a
public API.

Regards,
Rich Dougherty