Модульное тестирование и проверка значения частной переменной

Быстрый ответ заключается в том, что вам никогда не следует обращаться к закрытым членам из ваших модульных тестов. Это полностью противоречит цели наличия набора тестов, поскольку он блокирует вас во внутренних деталях реализации, которые вы, возможно, не захотите оставить в таком виде.

Более длинный ответ относится к тому, что делать дальше? В этом случае важно понимать, почему реализация такая, какая она есть (именно поэтому TDD настолько мощен, потому что мы используем тесты для определения ожидаемого поведения, но у меня такое ощущение, что вы не используют TDD).

В вашем случае первый вопрос, который приходит на ум: «Почему объекты IAuditable добавляются во внутренний список?» или, иначе говоря, «Каков ожидаемый видимый извне результат этой реализации?» В зависимости от ответа на эти вопросы, это вам нужно проверить.

Если вы добавляете объекты IAuditable во внутренний список, потому что позже захотите записать их в журнал аудита (просто предположение), то вызовите метод, который записывает журнал, и убедитесь, что ожидаемые данные были записаны.

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

Если вы добавили код без видимой причины, то удалите его снова :)

Важная часть состоит в том, что очень полезно тестировать поведение вместо реализации. Это также более надежная и удобная в обслуживании форма тестирования.

Не бойтесь модифицировать вашу тестируемую систему (SUT), чтобы сделать ее более тестируемой. Пока ваши дополнения имеют смысл в вашем домене и соответствуют лучшим методам объектно-ориентированной архитектуры, проблем нет - вы бы просто следовали принципу открытости / закрытости.

Вы не должны проверять список, в который был добавлен элемент. Если вы это сделаете, вы напишете модульный тест для метода Add из списка, а не для вашего кода. Просто проверьте возвращаемое значение OnSave; это действительно все, что вы хотите проверить.

Если вас действительно беспокоит Add, исключите его из уравнения.

Редактировать:

@TonE: После прочтения ваших комментариев я бы сказал, что вы можете изменить свой текущий метод OnSave, чтобы сообщать о сбоях. Вы можете создать исключение в случае сбоя приведения и т. Д. Затем вы можете написать модульный тест, который ожидает и исключение, а другой - нет.

Я бы сказал, что «лучшая практика» - это проверить что-то значимое с объектом, который изменился теперь, когда он сохранил сущность в списке.

Другими словами, какое поведение изменилось в классе теперь, когда он его сохранил, и проверить это поведение. Хранилище - это деталь реализации.

При этом это не всегда возможно.

При необходимости вы можете использовать отражение.

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

• NotIAuditableIsNotSaved
• IAuditableInstanceIsSaved
• IAuditableSubclassInstanceIsSaved

... и так далее.

Проблема в том, что, как вы заметили, учитывая код в вашем вопросе, вы можете сделать это только косвенно - только проверив частный член insertItems IList<object> (путем отражения или добавив свойство с единственной целью тестирования) или введя список в класс:

public class ClassToBeTested
{
    private IList _InsertItems = null;

    public ClassToBeTested(IList insertItems) {
      _InsertItems = insertItems;
    }
}

Затем просто протестировать:

[Test]
public void OnSave_Adds_Object_To_InsertItems_Array()
{
     Setup();

     List<object> testList = new List<object>();
     myClassToBeTested     = new MyClassToBeTested(testList);

     // ... create audiableObject here, etc.
     myClassToBeTested.OnSave(auditableObject, null);

     // Check auditableObject has been added to testList
}

Внедрение - наиболее перспективное и ненавязчивое решение, если только у вас нет причин полагать, что список будет ценной частью вашего общедоступного интерфейса (в этом случае добавление свойства может быть лучше - и, конечно, внедрение свойств также совершенно законно). Вы даже можете сохранить конструктор без аргументов, который обеспечивает реализацию по умолчанию (new List ()).

Это действительно хорошая практика; Он может показаться вам слишком сложным, учитывая, что это простой класс, но только тестируемость того стоит. Затем, вдобавок ко всему, если вы найдете другое место, где хотите использовать класс, это будет вишенкой на торте, поскольку вы не будете ограничены использованием IList (не то чтобы позже потребовалось много усилий, чтобы внести изменения. ).

Если список является деталью внутренней реализации (а кажется, что так оно и есть), то вам не следует его тестировать.

Хороший вопрос: каков будет поведение, если элемент будет добавлен в список? Для его запуска может потребоваться другой метод.

    public void TestMyClass()
    {
        MyClass c = new MyClass();
        MyOtherClass other = new MyOtherClass();
        c.Save(other);

        var result = c.Retrieve();
        Assert.IsTrue(result.Contains(other));
    }

В этом случае я утверждаю, что правильное внешне видимое поведение состоит в том, что после сохранения объекта он будет включен в полученную коллекцию.

Если результат таков, что в будущем переданный объект должен будет вызывать его при определенных обстоятельствах, тогда у вас может быть что-то вроде этого (простите, пожалуйста, псевдо-API):

    public void TestMyClass()
    {
        MyClass c = new MyClass();
        IThing other = GetMock();
        c.Save(other);

        c.DoSomething();
        other.AssertWasCalled(o => o.SomeMethod());
    }

В обоих случаях вы тестируете внешне видимое поведение класса, а не внутреннюю реализацию.

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

Теперь, если вы разрабатываете более крупные тесты, скажем, на уровне интеграции, тогда нет, вы не захотите писать в реализацию или тестировать частные методы, но вопрос был направлен в небольшую область модульного тестирования.