Как создать тесты для объектов Poco

Question

Я новичок в издевательстве / тестировании и хочу знать, какой уровень вы должны пройти при тестировании Например, в моем коде у меня есть следующий объект:

public class RuleViolation
{
    public string ErrorMessage { get; private set; }
    public string PropertyName { get; private set; }

    public RuleViolation( string errorMessage )
    {
        ErrorMessage = errorMessage;
    }

    public RuleViolation( string errorMessage, string propertyName )
    {
        ErrorMessage = errorMessage;
        PropertyName = propertyName;
    }
}

Это относительно простой объект. Итак, мой вопрос:

Требуется ли юнит-тест?

Если он делает то, что я проверяю и как?

Спасибо

Answer 1

не содержит никакой логики => нечего проверять

Answer 2

Я бы сказал, что, вероятно, нет. Единственное, что вы, вероятно, захотите проверить, если это чрезвычайно важно, - это модификаторы доступа:

public string ErrorMessage { get; private set; }
public string PropertyName { get; private set; }

Если действительно очень важно, чтобы код вне класса не мог их изменить, то это единственное, что я хотел бы попробовать и проверить.

Вот как вы можете получить аксессоры в свойстве:

class Program
    {
        static void Main(string[] args)
        {
            var property = typeof(Test).GetProperty("Accessor");

            var methods = property.GetAccessors();
        }
    }



    public class Test
    {
        public string Accessor
        {

            get;
            private set;
        }    

    }

С property.GetAccessors();

Вы можете видеть, есть ли сеттер. Если это так, то сеттер общедоступен. (Также есть свойства IsPrivate и IsPublic, которые вы можете использовать для проверки других Accessors).

Answer 3

Если бы это был мой код и мой объект, у меня были бы тесты для него, независимо от того, насколько прост или сложен класс, точка. Даже если класс кажется маловероятным, тесты - это то, где, IMO, вы документируете свои предположения, проектные решения и правильное использование.

Тем самым вы не только проверяете, что то, что у вас работает, работает как задумано, но у вас есть возможность продумать типичные сценарии (что происходит, если параметры ctor равны нулю или пусты или в конце есть пробел? Почему PropertyName необязательный в неизменяемом классе?).

И если (когда?) Требования меняются, у вас есть надежная отправная точка для решения этой проблемы. И если этот тривиальный класс как-то не очень хорошо взаимодействует со всеми другими классами, возможно, у вас есть тест, чтобы поймать его раньше, чем ваши клиенты.

Это просто правильный способ разработки вашего кода.

НТН,
Berryl

Answer 4

Вы можете протестировать этот объект, но это так просто, что не требует его. Тест будет что-то вроде (пример NUnit)

[Test]
public void TestRuleViolationConstructorWithErrorMessageParameterSetsErrorMessageProperty() {
    // Arrange
    var errorMessage = "An error message";

    // Act
    var ruleViolation = new RuleViolation(errorMessage);

    // Assert
    Assert.AreEqual(errorMessage, ruleViolation.ErrorMessage);
}

Однако нет смысла писать подобные тесты, поскольку вы проверяете, что свойства .NET Framework работают правильно. Как правило, вы можете доверять Microsoft, чтобы получить это право: -)

Что касается насмешек, это полезно, когда ваш тестируемый класс имеет зависимость, возможно, от другого класса в вашем собственном приложении или от типа из фреймворка. Фреймворки Mocking позволяют вам вызывать методы и свойства для зависимости без необходимости конкретно строить зависимость в коде и вместо этого позволяют вставлять определенные значения для свойств, возвращать значения для методов и т. Д. отличный фреймворк, и тест для базового класса с зависимостью будет выглядеть примерно так:

[Test]
public void TestCalculateReturnsBasicRateTaxForMiddleIncome() {
    // Arrange
    // TaxPolicy is a dependency that we need to manipulate.
    var policy = new Mock<TaxPolicy>();
    bar.Setup(x => x.BasicRate.Returns(0.22d));

    var taxCalculator = new TaxCalculator();

    // Act
    // Calculate takes a TaxPolicy and an annual income.  
    var result = taxCalculator.Calculate(policy.Object, 25000);

    // Assert
    // Basic Rate tax is 22%, which is 5500 of 25000.
    Assert.AreEqual(5500, result);
}  

TaxPolicy будет испытан модулем в его собственном приборе, чтобы убедиться, что он ведет себя правильно. Здесь мы хотим проверить, что TaxCalculator работает правильно, и поэтому мы смоделируем объект TaxPolicy, чтобы упростить наши тесты; при этом мы можем указать поведение только битов TaxPolicy, которые нас интересуют. Без этого нам нужно было бы создавать свернутые вручную макеты / заглушки / подделки или создавать реальные экземпляры TaxPolicy для передачи.

Однако у Мок есть нечто большее, чем это; Ознакомьтесь с кратким руководством по , чтобы узнать больше о том, что он может сделать.

Answer 5

Даже если все просто, в ваших конструкторах есть логика. Я бы проверил это:

RuleViolation ruleViolation = new RuleViolation("This is the error message");
Assert.AreEqual("This is the error message", ruleViolation.ErrorMessage);
Assert.IsEmpty(ruleViolation.PropertyName);

RuleViolation ruleViolation = new RuleViolation("This is the error message", "ThisIsMyProperty");
Assert.AreEqual("This is the error message", ruleViolation.ErrorMessage);
Assert.AreEqual("ThisIsMyProperty", ruleViolation.PropertyName);