有没有更简单的方法来测试不可变对象中的参数验证和字段初始化？

我的领域包括许多简单的不可变类，如下所示：

public class Person
{
    public string FullName { get; }
    public string NameAtBirth { get; }
    public string TaxId { get; }
    public PhoneNumber PhoneNumber { get; }
    public Address Address { get; }

    public Person(
        string fullName,
        string nameAtBirth,
        string taxId,
        PhoneNumber phoneNumber,
        Address address)
    {
        if (fullName == null)
            throw new ArgumentNullException(nameof(fullName));
        if (nameAtBirth == null)
            throw new ArgumentNullException(nameof(nameAtBirth));
        if (taxId == null)
            throw new ArgumentNullException(nameof(taxId));
        if (phoneNumber == null)
            throw new ArgumentNullException(nameof(phoneNumber));
        if (address == null)
            throw new ArgumentNullException(nameof(address));

        FullName = fullName;
        NameAtBirth = nameAtBirth;
        TaxId = taxId;
        PhoneNumber = phoneNumber;
        Address = address;
    }
}

编写空检查和属性初始化已经非常繁琐，但是目前我为这些类中的每一个编写单元测试，以验证参数验证是否正常工作以及所有属性都已初始化。感觉就像无聊的忙碌而带来的好处是不相称的。

真正的解决方案是让C＃原生支持不变性和非空引用类型。但是与此同时，我该怎么做才能改善这种情况呢？是否值得编写所有这些测试？为此类编写代码生成器以避免为每个类编写测试是一个好主意吗？

这是我现在根据答案得到的。

我可以简化null检查和属性初始化，使其看起来像这样：

FullName = fullName.ThrowIfNull(nameof(fullName));
NameAtBirth = nameAtBirth.ThrowIfNull(nameof(nameAtBirth));
TaxId = taxId.ThrowIfNull(nameof(taxId));
PhoneNumber = phoneNumber.ThrowIfNull(nameof(phoneNumber));
Address = address.ThrowIfNull(nameof(address));

使用Robert Harvey的以下实现：

public static class ArgumentValidationExtensions
{
    public static T ThrowIfNull<T>(this T o, string paramName) where T : class
    {
        if (o == null)
            throw new ArgumentNullException(paramName);

        return o;
    }
}

使用GuardClauseAssertionfrom 很容易测试空检查AutoFixture.Idioms（感谢建议，Esben Skov Pedersen）：

var fixture = new Fixture().Customize(new AutoMoqCustomization());
var assertion = new GuardClauseAssertion(fixture);
assertion.Verify(typeof(Address).GetConstructors());

这可以进一步压缩：

typeof(Address).ShouldNotAcceptNullConstructorArguments();

使用此扩展方法：

public static void ShouldNotAcceptNullConstructorArguments(this Type type)
{
    var fixture = new Fixture().Customize(new AutoMoqCustomization());
    var assertion = new GuardClauseAssertion(fixture);

    assertion.Verify(type.GetConstructors());
}

我正是针对这种情况创建了一个t4模板。为了避免为不可变类编写大量样板。

https://github.com/xaviergonz/T4Immutable T4Immutable是C＃.NET应用程序的T4模板，可为不可变类生成代码。

如果您使用此方法，则专门讨论非null测试：

[PreNotNullCheck, PostNotNullCheck]
public string FirstName { get; }

构造函数将是这样的：

public Person(string firstName) {
  // pre not null check
  if (firstName == null) throw new ArgumentNullException(nameof(firstName));

  // assignations + PostConstructor() if needed

  // post not null check
  if (this.FirstName == null) throw new NullReferenceException(nameof(this.FirstName));
}

话虽如此，如果您使用JetBrains注释进行空检查，您也可以这样做：

[JetBrains.Annotations.NotNull, ConstructorParamNotNull]
public string FirstName { get; }

构造函数将是这样的：

public Person([JetBrains.Annotations.NotNull] string firstName) {
  // pre not null check is implied by ConstructorParamNotNull
  if (firstName == null) throw new ArgumentNullException(nameof(firstName));

  FirstName = firstName;
  // + PostConstructor() if needed

  // post not null check implied by JetBrains.Annotations.NotNull on the property
  if (this.FirstName == null) throw new NullReferenceException(nameof(this.FirstName));
}

还有比这更多的一些功能。

通过一个简单的重构，您可以得到一些改进，可以缓解编写所有这些栅栏的问题。首先，您需要以下扩展方法：

internal static T ThrowIfNull<T>(this T o, string paramName) where T : class
{
    if (o == null)
        throw new ArgumentNullException(paramName);

    return o;
}

然后，您可以编写：

public class Person
{
    public string FullName { get; }
    public string NameAtBirth { get; }
    public string TaxId { get; }
    public PhoneNumber PhoneNumber { get; }
    public Address Address { get; }

    public Person(
        string fullName,
        string nameAtBirth,
        string taxId,
        PhoneNumber phoneNumber,
        Address address)
    {
        FullName = fullName.ThrowIfNull(nameof(fullName));
        NameAtBirth = nameAtBirth.ThrowIfNull(nameof(nameAtBirth));
        TaxId = taxId.ThrowIfNull(nameof(taxId));
        PhoneNumber = phoneNumber.ThrowIfNull(nameof(fullName));
        Address = address.ThrowIfNull(nameof(address));
    }
}

在扩展方法中返回原始参数会创建一个流畅的界面，因此您可以根据需要使用其他扩展方法来扩展此概念，并将它们链接在一起以进行分配。

其他技术在概念上更优雅，但在执行上却越来越复杂，例如，用[NotNull]属性修饰参数，并像这样使用Reflection 。

也就是说，除非您的类是面向公众的API的一部分，否则您可能不需要所有这些测试。

短期而言，编写此类测试的乏味性无济于事。但是，由于将在下个月发布的C＃（v7）的下一版本中实现，因此抛出表达式有一些帮助：

public class Person
{
    public string FullName { get; }
    public string NameAtBirth { get; }
    public string TaxId { get; }
    public PhoneNumber PhoneNumber { get; }
    public Address Address { get; }

    public Person(
        string fullName,
        string nameAtBirth,
        string taxId,
        PhoneNumber phoneNumber,
        Address address)
    {
        FullName = fullName ?? throw new ArgumentNullException(nameof(fullName));
        NameAtBirth = nameAtBirth ?? throw new ArgumentNullException(nameof(nameAtBirth));
        TaxId = taxId ?? throw new ArgumentNullException(nameof(taxId)); ;
        PhoneNumber = phoneNumber ?? throw new ArgumentNullException(nameof(phoneNumber)); ;
        Address = address ?? throw new ArgumentNullException(nameof(address)); ;
    }
}

您可以通过Try Roslyn webapp尝试使用throw表达式。

我很惊讶没有人提到NullGuard.Fody。可通过NuGet获得，并将在编译时自动将这些空检查编织到IL中。

所以您的构造函数代码将仅仅是

public Person(
    string fullName,
    string nameAtBirth,
    string taxId,
    PhoneNumber phoneNumber,
    Address address)
{
    FullName = fullName;
    NameAtBirth = nameAtBirth;
    TaxId = taxId;
    PhoneNumber = phoneNumber;
    Address = address;
}

NullGuard会为您添加这些null检查，以将其完全转换为您编写的内容。

但是请注意，NullGuard是opt-out，也就是说，它将为所有方法和构造函数参数，属性getter和setter甚至检查方法返回值添加这些空检查，除非您明确允许该[AllowNull]属性使用空值。

是否值得编写所有这些测试？

不，可能不会。您将其搞砸的可能性有多大？一些语义从您的身下改变出来的可能性有多大？如果有人搞砸了会有什么影响？

如果您花费大量时间对几乎不会损坏的东西进行测试，并且这样做确实是微不足道的修复……也许不值得。

为此类编写代码生成器以避免为每个类编写测试是一个好主意吗？

也许？用反射可以很容易地完成这种事情。要考虑的是在为真实代码生成代码，因此您没有N个类可能会出现人为错误。错误预防>错误检测。

是否值得编写所有这些测试？

不会。因为我很确定您已经通过其他一些使用这些类的逻辑测试来测试了这些属性。

例如，您可以对Factory类进行测试，这些测试具有基于这些属性的断言（Name例如，使用适当分配的属性创建的实例）。

如果那些类暴露给某些第三方/最终用户使用的公共API（@EJoshua，请注意），然后测试预期的 ArgumentNullException可能会有用。

等待C＃7时，可以使用扩展方法

public MyClass(string name)
{
    name.ThrowArgumentNullExceptionIfNull(nameof(name));
}

public static void ThrowArgumentNullExceptionIfNull(this object value, string paramName)
{
    if(value == null)
        throw new ArgumentNullException(paramName);
}

对于测试，您可以使用一种参数化测试方法，该方法使用反射null为每个参数创建引用，并为预期的异常声明。

您总是可以编写如下方法：

// Just to illustrate how to call this
private static void SomeMethod(string a, string b, string c, string d)
    {
        ValidateArguments(a, b, c, d);
        // ...
    }

    // This is the one to use as a utility function
    private static void ValidateArguments(params object[] args)
    {
        for (int i = 0; i < args.Length; i++)
        {
            if (args[i] == null)
            {
                StackTrace trace = new StackTrace();
                // Get the method that called us
                MethodBase info = trace.GetFrame(1).GetMethod();

                // Get information on the parameter that is null so we can add its name to the exception
                ParameterInfo param = info.GetParameters()[i];

                // Raise the exception on behalf of the caller
                throw new ArgumentNullException(param.Name);
            }
        }
    }

如果您有几种需要这种验证的方法，那么至少可以节省一些键入时间。当然，此解决方案假定没有你的方法的参数都可以null，但你可以修改这个改变，如果你愿意的话。

您还可以扩展它以执行其他特定于类型的验证。例如，如果您有一个规则，即字符串不能完全为空格或为空，则可以添加以下条件：

// Note that we already know based on the previous condition that args[i] is not null
else if (args[i].GetType() == typeof(string))
            {
                string argCast = arg as string;

                if (!argCast.Trim().Any())
                {
                    ParameterInfo param = GetParameterInfo(i);

                    throw new ArgumentException(param.Name + " is empty or consists only of whitespace");
                }
            }

我所引用的GetParameterInfo方法基本上是反射操作（因此，我不必一遍又一遍地键入相同的内容，这将违反DRY原理）：

private static ParameterInfo GetParameterInfo(int index)
    {
        StackTrace trace = new StackTrace();

        // Note that we have to go 2 methods back to get the ValidateArguments method's caller
        MethodBase info = trace.GetFrame(2).GetMethod();

        // Get information on the parameter that is null so we can add its name to the exception
        ParameterInfo param = info.GetParameters()[index];

        return param;
    }

我不建议从构造函数中抛出异常。问题是您将很难测试它，因为您必须传递有效参数，即使它们与您的测试无关。

例如：如果要测试第三个参数是否引发异常，则必须正确传递第一个和第二个参数。因此，您的测试不再孤立了。当第一个和第二个参数的约束更改时，即使测试第三个参数，该测试用例也会失败。

我建议使用Java验证API并外部化验证过程。我建议涉及四个职责（类）：

1. 一个带有Java验证注释参数的建议对象，它带有一个validate方法，该方法返回一组ConstraintViolations。优点之一是，您可以在不声明有效的情况下绕过该对象。您可以将验证延迟到需要时，而不必尝试实例化域对象。验证对象可以在不同的层中使用，因为它是没有层特定知识的POJO。它可以是您的公共API的一部分。

2. 域对象的工厂，负责创建有效对象。您传入建议对象，如果一切正常，工厂将调用验证并创建域对象。

3. 域对象本身，对于其他开发人员来说，实例化应该几乎不可访问。出于测试目的，我建议在包范围内使用此类。

4. 一个公共域接口，用于隐藏具体的域对象并使滥用变得困难。

我不建议检查空值。只要进入域层，只要您没有带有结尾的对象链或单个对象的搜索功能，就无需传递null或返回null。

还有一点：编写尽可能少的代码并不是衡量代码质量的指标。考虑一下32k游戏竞赛。该代码是您可以拥有的最紧凑但也是最混乱的代码，因为它只关心技术问题，而不关心语义。但是语义是使事情变得全面的要点。