Re: Method of Unit Testing Private Methods

• Previous message: Matthias: "Re: help with program idea"
• In reply to: The Weeg: "Method of Unit Testing Private Methods"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: 6 Feb 2005 12:06:13 -0800

The Weeg wrote:
> I'm relatively new to the concept of unit testing, and I've quickly
run
> into the problem of how to properly unit test private methods of a
> class. [...]

I follow the philosophy that, if it's private, then its none of my
business whether it works correctly and consider the class to be
functionally correct, if unit tests on its public members run
successfully. In other words, I infer the correctness of private
members, via the correctness of the public members that use those
private members.

Then when I *do* need access to the private members for some reason
(mostly happens with private data members), I use conditional
compilation to alter the visibility of the member:

  #If DEBUG Then
     Public Foo As Bar
  #Else
     Private Foo As Bar
  #End If

or as follows for procedures:

  #If DEBUG Then
     Public Sub Foo()
  #Else
     Private Sub Foo()
  #End If

     'procedure body goes here

     End Sub

This way, I can access the member in debug builds which run the unit
tests, and keep it hidden in release builds meant for general use.
Needless to say, I only use this method for the rare cases where I
*must* have access to the private member in order to write any
meaningful test. If overused, the conditional compilation code makes it
all look, er, ugly.

Further, I personally wouldn't use the method of inheritance or
interfaces just to facilitate testing of private members. It smacks of
OOP abuse, but YMMV.

Cheers,
Eric Mutta :-)

• Previous message: Matthias: "Re: help with program idea"
• In reply to: The Weeg: "Method of Unit Testing Private Methods"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]