使用内部构造函数和私有设置程序对域对象进行单元测试

Question

I have defined a Person class in a project called Tools.Client, which is a wrapper around a web service API. Person is constructed with the XML returned by the service.

public class Person
{
  internal Person(XElement personElement)
  {
    this.FirstName = personElement.Element("first_name").Value;
    this.LastName = personElement.Element("last_name").Value;

    this.Jobs = new List<Job>();
    foreach (var jobElement in personElement.Elements("jobs"))
    {
      this.Jobs.Add(new Job(jobElement));
    }
  }

  public string FirstName {get; private set;}
  public string LastName {get; private set;}
  public ICollection<Job> {get; private set;}
}

I have another class called Analyzer in a separate project called Tools.Analysis, which contains analysis logic to run against data retrieved from the API client.

private readonly ICollection<Person> _people;
public Analyzer(ICollection<Person> people)
{
  _people = people;
}

public AnalysisResult Analyze()
{
  var result = new AnalysisResult();

  foreach (var person in _people)
  {
    // do some analysis, store data in the result
  }

  return result;
}

I would like to write a unit test for the Analyzer class's Analyze method, but I am not sure how I want to get around the following issues:

1. Person has an internal constructor method with an XElement parameter. I do not want to create manual XElement objects in my unit tests.

2. Person has private setters (as I think it should, I do not want users of Tools.Client altering data returned from the API). This problem is exacerbated by the additional dependency on Job, which has a similar structure.

I can think of a few solutions to this, but do not know which will be the most maintainable over time:

1. Create IPerson and IJob interfaces and use mocks or simple test implementations of these interfaces.
2. Expose public setters for easy testing (again, I don't really like this). I think I could also use internal setters with the InternalsVisibleTo attribute (not as bad as public, but still not what I want).
3. Move XML parsing outside of the constructor , and have the constructor take the parameters firstName, lastName, jobs. The constructor can still be internal, I will just need to use the InternalsVisibleTo attribute on my assembly.

Answer 1

I think you should move xml parsing from Person into a separate factory-like class, make Person immutable value-object-like class. This way you won't need to mock them, you should be able to create real instances of Person and Job for testing Analyzer .

Answer 2

I agree that you don't want to make your setters public. You have an immutable class now, and you should not give that up lightly.

Interfaces on value objects are OK, but they are often overdesign. Avoid that if there is a better solution.

Go with option 3. Xml parsing is really a responsibility of another class; Person should only be a data object.

If you can't do that, at the very least create a constructor without it. This is not great because your constructors could possible diverge (they can't easily be made to call one another), but it's incrementally better than where you are.

public class Person
{
  internal Person(XElement personElement)
  {
    this.FirstName = personElement.Element("first_name").Value;
    this.LastName = personElement.Element("last_name").Value;

    this.Jobs = new List<Job>();
    foreach (var jobElement in personElement.Elements("jobs"))
    {
      this.Jobs.Add(new Job(jobElement));
    }
  }

  internal Person(string firstName, string lastName, ICollection<Job> jobs)
  {
     //set properties
  }

  public string FirstName {get; private set;}
  public string LastName {get; private set;}
  public ICollection<Job> {get; private set;}
}