불변 개체에서 인수 유효성 검사 및 필드 초기화를 테스트하는 더 쉬운 방법이 있습니까?

내 도메인은 다음과 같은 간단한 불변 클래스로 구성됩니다.

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;
    }
}

null 검사와 속성 초기화를 작성하는 것은 이미 매우 지루하지만 현재 는 각 클래스에 대한 단위 테스트 를 작성 하여 인수 유효성 검사가 올바르게 작동하고 모든 속성이 초기화되었는지 확인합니다. 이것은 유익하지 않은 혜택으로 극도로 지루한 바쁜 일과 같습니다.

실제 솔루션은 C #이 기본적으로 불변성과 null이 아닌 참조 유형을 지원하는 것입니다. 그러나 그 동안 상황을 개선하기 위해 어떻게해야합니까? 이 모든 테스트를 쓸 가치가 있습니까? 각 클래스에 대한 테스트 작성을 피하기 위해 해당 클래스에 대한 코드 생성기를 작성하는 것이 좋은 생각입니까?

여기에 내가 대답을 바탕으로 한 것이 있습니다.

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을 사용하여 null 검사를 테스트하는 것은 쉽습니다 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 Annotations를 사용하면 다음과 같이 할 수도 있습니다.

[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) 릴리스의 일부로 구현 될 예정이므로 다음 몇 달 내에 발생할 수있는 throw 표현식에 도움이 될 수 있습니다.

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를 언급 하지 않은 것에 놀랐습니다 . NuGet을 통해 사용할 수 있으며 컴파일 시간 동안 null 검사를 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는 옵트 아웃입니다 . 즉 , 속성과 함께 null 값 을 명시 적으로 허용 하지 않는 한 모든 null 메서드 를 모든 메서드 및 생성자 인수, 속성 getter 및 setter에 추가하고 메서드 반환 값을 확인 합니다.[AllowNull]

이 모든 테스트를 쓸 가치가 있습니까?

아마 아닐 것입니다. 당신이 그것을 망칠 가능성은 무엇입니까? 어떤 의미론이 당신 아래에서 변할 가능성은 무엇입니까? 누군가 그것을 망치면 어떤 영향이 있습니까?

거의 깨지지 않을 무언가에 대한 테스트를하는 데 많은 시간을 소비하고 있다면 그럴 경우 사소한 해결책입니다 ... 아마도 가치가 없습니다.

각 클래스에 대한 테스트 작성을 피하기 위해 해당 클래스에 대한 코드 생성기를 작성하는 것이 좋은 생각입니까?

아마도? 그런 종류의 일은 반성을 통해 쉽게 할 수 있습니다. 고려해야 할 것은 실제 코드에 대한 코드 생성을 수행하는 것이므로 사람 오류가있을 수있는 N 클래스가 없습니다. 버그 예방> 버그 탐지.

이 모든 테스트를 쓸 가치가 있습니까?

아니요
. 클래스가 사용되는 다른 로직 테스트를 통해 해당 속성을 테스트했다고 확신합니다.

예를 들어, 해당 속성을 기반으로 어설 션이있는 팩토리 클래스에 대한 테스트를 가질 수 있습니다 ( Name예를 들어 올바르게 지정된 속성으로 작성된 인스턴스 ).

이러한 클래스가 일부 제 3 자 / 최종 사용자가 사용하는 공개 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 유효성 검증 주석이있는 제안 오브젝트는 ConstraintViolations 세트를 리턴하는 validate 메소드로 매개 변수에 주석이 달린 매개 변수를 사용했습니다. 한 가지 장점은 유효한 주장없이이 개체를 전달할 수 있다는 것입니다. 도메인 개체를 인스턴스화하지 않고 필요할 때까지 유효성 검사를 지연시킬 수 있습니다. 유효성 검사 개체는 레이어 별 지식이없는 POJO이므로 다른 레이어에서 사용할 수 있습니다. 공개 API의 일부가 될 수 있습니다.

2. 유효한 객체를 만드는 도메인 객체의 팩토리. 제안 오브젝트를 전달하면 팩토리가 유효성 검증을 호출하고 모든 것이 정상인 경우 도메인 오브젝트를 작성합니다.

3. 다른 개발자의 인스턴스화를 위해 대부분 액세스 할 수없는 도메인 객체 자체입니다. 테스트 목적으로이 클래스를 패키지 범위에 두는 것이 좋습니다.

4. 구체적 도메인 개체를 숨기고 잘못 사용하기위한 퍼블릭 도메인 인터페이스.

null 값을 확인하지 않는 것이 좋습니다. 도메인 계층에 들어가 자마자 단일 객체에 대한 종료 또는 검색 기능이있는 객체 체인이없는 한 null을 전달하거나 null을 반환하지 않습니다.

또 다른 요점 : 가능한 한 적은 코드를 작성하는 것은 코드 품질에 대한 척도가 아닙니다. 32k 게임 경쟁에 대해 생각해보십시오. 이 코드는 기술적 인 문제에만 관심이 있고 의미론에는 신경 쓰지 않기 때문에 가장 간결하지만 가장 지저분한 코드입니다. 그러나 의미론은 사물을 포괄적으로 만드는 요점입니다.