Hi Brian,

At a casual glance I would say that your class is doing too much. Loading a web 
page and parsing
seem like two distinct responsibilities (in addition to whatever else the class 
is doing). I
prefer classes that have a single responsibility. I see that you don't like 
using mock objects,
but one nice side effect is that it forces classes to be smaller and better 
defined IMHO. For
example, whilst I cannot tell what class the sample method came from, I would 
say that said class
is using a page loader of some kind and html parser class. By using Inversion 
of Control the
classes containing this functionality can be passed in by constructor injection 
allowing you to
substitute them for a mock class whose expectations you can control to verify 
correct behaviour of
the class under test. You might want to do some research around the threads on 
state versus
behavioral testing.

http://www.martinfowler.com/articles/injection.html
http://www.picocontainer.org/Constructor+Injection
http://portal.acm.org/citation.cfm?id=1028765  PDF: "Mock Roles not Objects"

Paul

--- Brian - IT Department <[EMAIL PROTECTED]> wrote:

> Paul,
>
> I would tend to agree that private methods shouldn't be tested.  The
> question was how to test private/internal methods, so I pointed out a way
> of testing them.  I have found this necessary in some instances (maybe you
> know a more elegant way to do this?).  For example:
>
> // simplified w/o error trapping, etc.
> public ArrayList GetInformationFromInternet(...)
> {
>     string htmlResponse = GetWebPage();
>     return ParseHtmlPage(htmlResponse);
> }
>
> ParseHtmlPage is a private method and also the main method that I want to
> test with different html inputs.  The information on the internet is
> different every day for my purpose.  I've written my unit tests for
> ParseHtmlPage with different inputs using the method I mentioned in the
> previous email.  I realize I could get more complicated and write another
> object to return specific web pages.
>
> If you have a good way to do that without making ParsePage a public method
> I would be very interesting in hearing about it.  I've used mock objects
> to seperate communications out, but have found that sometimes they are a
> lot of unnecessary work.
>
> Thanks,
> Brian
>
> On Mon, October 17, 2005 10:38 am, Paul Gale said:
> > I think that something is being missed on this thread. An earlier poster
> > pointed out that private
> > methods should not be tested. I agree with that. After all, any private
> > method should be present
> > in support of a public method of some kind. Therefore test the public
> > interface of your class only
> > and all other private methods that are invoked by this public method will
> > be touched by the unit
> > test accordingly. By making tests too aware of the internals of your class
> > you can end up with
> > very brittle tests. Having to modify a unit test just because the
> > internals of the class changed
> > is not good.
> >
> > Paul
> >
> >
> > --- Brian - IT Department <[EMAIL PROTECTED]> wrote:
> >
> >> > How do I write tests for internal and private methods and classes?
> >> One way is to make a public class that inherits from the class with
> >> private and internal methods and make public methods with identical
> >> signatures (using the 'new' keyword) for the internal and private
> >> methods.
> >>  This class should be conditionally compiled out of the release build
> >> and
> >> in a test namespace, though.
> >>
> >> > How do I control the order of the various tests?
> >> All tests must be order independant.
> >>
> >> > How do I control the environment (start and stop applications that the
> >> > code being tested is supposed to communicate with)?
> >> Looked at the setup and teardown attributes.  Maybe look into mock
> >> objects
> >> to simulate the environment.
> >>
> >> > Do you know any good articles I should read (that goes beyond the
> >> scope of
> >> > getting started)?
> >> Based on your questions, I think you need to read articles on the scope
> >> of
> >> getting started first.  Buy a book like "working effectively with legacy
> >> code" or "test-driven development".
> >>
> >> -- Brian
> >>
> >> ===================================
> >> This list is hosted by DevelopMentor®  http://www.develop.com
> >>
> >> View archives and manage your subscription(s) at
> >> http://discuss.develop.com
> >>
> >
> > ===================================
> > This list is hosted by DevelopMentor®  http://www.develop.com
> >
> > View archives and manage your subscription(s) at
> > http://discuss.develop.com
> >
> >
>
> ===================================
> This list is hosted by DevelopMentor®  http://www.develop.com
>
> View archives and manage your subscription(s) at http://discuss.develop.com
>

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com

Reply via email to