What is the impact on testability for an associations passed as parameters to a class?

Question

I am working on an OO design problem. I'll try to focus on the part I am confused about and explain it in text rather than providing code.

I have a class called SalesPolicy that contains a List of TaxPolicy. TaxPolicy is an abstract class that represents a tax policy with name and tax rate as attributes. TaxPolicy contains an abstract method called accept. Concrete implementations of a TaxPolicy must implement the accept method and provide the logic for deciding when a TaxPolicy is applicable.

I have another class called SalesEngine. SalesEngine has a SalesPolicy and SalesPolicy is one of the parameters to the SalesEngine constructor. SalesEngine decides whether a TaxPolicy from a List of TaxPolicy in SalesPolicy is applicable for an item or not by calling the accept method and then calculates the tax accordingly. As explained earlier, SalesPolicy contains a single attribute which is a list of TaxPolicy and a method to add to the List.

What I need to know is whether it is okay to have a parameter like SalesPolicy for the SalesEngine class. What impact does this have from the point of view of testable code?

Answer 1

I think that it is perfectly fine to have a scenario like this:

public SalesEngine(SalesPolicy policy) { ... }

Where when the SalesEngine is being created the user or whoever already knows what SalesPolicy that they want to use.

Another scenario it might be valuable to include is the case where the user does not know what SalesPolicy they want to use at the time the SalesEngine is created, which you can do by adding a default constructor and a setter method:

// default construtor
public SalesEngine() { ... }

// sets the sales policy
public void setSalesPolicy(SalesPolicy policy){ ... } 

Answer 2

I agree with Hunter's answer that your description sounds reasonable (and that, depending on how it will be used, it might be useful to allow the SalesPolicy to be added later). So here I'll address your question about testing. The short answer is that it doesn't really change much.

Assuming that the SalesEngine needs a SalesPolicy object in order to do its thing, it's going to have to get it one way or another. Presumably the testing difficulties will be in testing a good representative range of SalesPolicy objects. But whether you're giving that as part of the constructor or adding it later doesn't really make that any easier or harder.

If, on the other hand, a SalesEngine doesn't always need a SalesPolicy to work, then you should definitely take Hunter's suggestion. That would be a more appropriate interface and would ease the testing burden in the cases when no SalesPolicy is needed.