How to test a method

[jehugaleahsa]

Also, one easy way to deal with this scenario without needing to introduce a
bunch of interfaces, etc, is to separate the data fetching from the data
processing.  Unlike dependency injection, this method will let the caller
remain agnostic of the change:

public string mainmethod()
{
    return mainMethodImpl(submethod());

}

string mainMethodImpl(string var)
{
    ...

}

now mainMethodImpl is easily tested, but callers can keep on using
mainmethod with the same interface as before.- Hide quoted text -

- Show quoted text -

Could you explain this a little further for me? I don't think I quite
understand. Is this some sort of strategy pattern? How can the data
fetching (assumingly in the submethod method) be avoided during test?

Thanks,
Travis

 

[jehugaleahsa]

As Ben says, you test mainMethodImpl(), not mainmethod().  Thus, you pass  
to it whatever mock data you would have in an dependency injection  
scenario.

Pete- Hide quoted text -

- Show quoted text -

I was reading some posts on Martin Fowler's wiki.

http://martinfowler.com/bliki/InversionOfControl.html
http://www.martinfowler.com/articles/injection.html

They explained it fairly well. It is a generic term. It can be
implemented in terms of strategy, dependency injection, template
method, etc.

The template method doesn't seem like a good idea to me. You'd have to
be extremely careful not to place testable code in the overriden
method. It also seems to violate the Single Responsibility Principle
(SRP).

I think the stategy method _is_ the dependency injection method. You
simply pass in which strategy/depended-on component (DOC) to use.

Personally, this is what I do:

At the bottom of my application I create a facade (which implements an
interface) for each distinct DOC or related DOCs. During test, I can
create a single stub for the facade.

At the top of my application I create a Singleton (called the
Registry) that provides methods that hit the DOCs internally. I
provide methods, instead of providing access to facades directly, so
that the business layer isn't coupled to the DOCs. So really, once the
Registry is set up to use production DOCs, the rest of the system in
oblivious. Of course, the entirety of my business layer is tied to my
Registry. In practice this hasn't been a big issue, even in my larger
applications. Also, the Registry can have a multitude of methods, so I
can have the Registry implement multiple interfaces and have multiple
static getters: one for each subset of methods. Or I can have multiple
Registries. I also tend to do exception handling in the Registry,
which frees up my business layer from doing it. My Registries tend to
very large and disjoint. Again this isn't usually a problem because
there isn't much in the way of logic. Registries also put everything
at the top of the application, so you don't have to go all out in
testing them.

I usually create setters on the Registry for setting the DOCs. I hide
the setters behind yet another interface. I usually have a class
called Process (horrible name) that creates a production version of
each DOC and places it in the Registry. In test, I duplicate this
initialization code but use the test facade stubs instead.

Usually my classes are fine grain enough that I can test most of them
without needing the registry at all. It's the actual business logic
that requires all this time and attention. I hate to say it, but I
also make a lot of classes public that should really be internal. I
prefer testability of proper visibility in most cases. If your classes
have well-defined interfaces and are cohesive, making them public
doesn't really spill the beans, you know what I mean?

I'm still developing this technique. I'd love to hear in more detail
how other developers are testing, too.

 

[jehugaleahsa]

As Ben says, you test mainMethodImpl(), not mainmethod().  Thus, you pass  
to it whatever mock data you would have in an dependency injection  
scenario.

Pete- Hide quoted text -

- Show quoted text -

I was reading some posts on Martin Fowler's wiki.

http://martinfowler.com/bliki/InversionOfControl.html
http://www.martinfowler.com/articles/injection.html

They explained it fairly well. It is a generic term. It can be
implemented in terms of strategy, dependency injection, template
method, etc.

The template method doesn't seem like a good idea to me. You'd have to
be extremely careful not to place testable code in the overriden
method. It also seems to violate the Single Responsibility Principle
(SRP).

I think the stategy method _is_ the dependency injection method. You
simply pass in which strategy/depended-on component (DOC) to use.

Personally, this is what I do:

At the bottom of my application I create a facade (which implements an
interface) for each distinct DOC or related DOCs. During test, I can
create a single stub for the facade.

At the top of my application I create a Singleton (called the
Registry) that provides methods that hit the DOCs internally. I
provide methods, instead of providing access to facades directly, so
that the business layer isn't coupled to the DOCs. So really, once the
Registry is set up to use production DOCs, the rest of the system in
oblivious. Of course, the entirety of my business layer is tied to my
Registry. In practice this hasn't been a big issue, even in my larger
applications. Also, the Registry can have a multitude of methods, so I
can have the Registry implement multiple interfaces and have multiple
static getters: one for each subset of methods. Or I can have multiple
Registries. I also tend to do exception handling in the Registry,
which frees up my business layer from doing it. My Registries tend to
very large and disjoint. Again this isn't usually a problem because
there isn't much in the way of logic. Registries also put everything
at the top of the application, so you don't have to go all out in
testing them.

I usually create setters on the Registry for setting the DOCs. I hide
the setters behind yet another interface. I usually have a class
called Process (horrible name) that creates a production version of
each DOC and places it in the Registry. In test, I duplicate this
initialization code but use the test facade stubs instead.

Usually my classes are fine grain enough that I can test most of them
without needing the registry at all. It's the actual business logic
that requires all this time and attention. I hate to say it, but I
also make a lot of classes public that should really be internal. I
prefer testability of proper visibility in most cases. If your classes
have well-defined interfaces and are cohesive, making them public
doesn't really spill the beans, you know what I mean?

I'm still developing this technique. I'd love to hear in more detail
how other developers are testing, too.