Тестирование поведения против реализации

Question

Мне было поручено внести небольшое изменение в кодовую базу без тестов, и я впервые пытаюсь реализовать изменение с использованием TDD, но я борюсь с разницей между реализацией тестирования и поведением. Система, над которой я работаю, отображает настраиваемые пользователем элементы списка. Пользователь может вносить изменения в поведение элементов списка через глобальную систему предпочтений, управляемую XML DAO:

class Preference {
  boolean getX();
  boolean getY();
}

Мне было поручено добавить Z в этот DAO, я реализовал это изменение и добавил тесты вобеспечить сериализацию и десериализацию значения, как я и ожидал.

Следующий класс элементов списка должен затем получить значение Z:

class ListItemA extends ListItem {
  private boolean Z;

  ListItemA(boolean Z){
    this.Z = Z;
  }

  OpenAction getOpenAction(){
    OpenAction action = new OpenAction();

    if(Z){
       action.addValue('Filter', true);
    }

    return action;
  }
}

Я также написал тесты, чтобы убедиться, что возвращаемое действие отражает поле Z. Связь между этими двумя аспектами заключается в том, где я борюсь, существует класс контроллера, который вызывается при рендеринге элементов списка:

class Controller {
  private Preference preference;

  Controller(Preference preference){
    this.preference = preference;
  }

  List<ListItem> getListItems(State state){
    // a bunch condition statements concerning the state
    List<ListItem> items = new List();

    if(state.items.includes('ListItemA')){
      ListItemA item = new ListItemA();
    }

    return items;
  }

}

Когда создается экземпляр ListItemA, мне теперь нужно передать getZ () из поля настроекно TDD говорит, что я не могу сделать это изменение без неудачного теста.

Я мог бы смоделировать предпочтение, смоделировать состояние, сгенерировать список и затем написать тот же тест, чтобы убедиться, что OpenAction отражает значение Z, но похоже, что я тестирую реализацию и пишу хрупкий тест. Кроме того, в тесте ListItem будет много дублированного тестового кода, поскольку они делают одно и то же утверждение. Другой альтернативой может быть отказ от теста ListItem и добавление всех утверждений в тесте Controller, но похоже, что я тестирую другую систему.

Мои вопросы:

• Как провести грань между тестированием реализации и написанием слишком широких тестов?

• Как бы вы подошли к тестированию этой ситуации?

• Я переоцениваю?

• Я подхожу к изменениям в этой унаследованной системе через TDD, согласно только что законченной книге «Эффективная работа в устаревшем коде», соответствует ли описанный выше метод процессу, которым я должен бытьпредпринять при приближении к такой системе?

• Есть ли какие-нибудь хорошие статьи, книги или ресурсы, о которых я могу прочитать, чтобы углубить мое понимание этой области?

• Как мне поступитьо тестировании устаревшей системы на рабочем месте с культурой отсутствия тестирования? У меня нет своих собственных систем для работы, как я могу получить опыт?

Answer 1

Как провести грань между реализацией тестирования и написанием слишком широких тестов?

Широкие тесты, как правило, наиболее проблематичны, когда охватывают несколько нестабильных поведений - каждый раз, когда один изэто поведение меняется, как и тесты. Обычно это не проблема в одном сеансе редактирования - потому что даже нестабильное поведение имеет тенденцию быть «стабильным» в течение достаточно короткого периода времени.

Если унаследованный код, с которым вы работаете, фиксирует свою историю изменений (например:система управления исходным кодом), то вы можете посмотреть, какие части кода были стабильны, и предположить, что эвристическая «вчерашняя погода» будет сохраняться.

Я мог бы высмеивать предпочтения, высмеиватьstate,

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

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

Как мне провести тестирование устаревшей системы на рабочем месте с культурой отсутствия тестирования? ?

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