Должен ли я изменить код, чтобы сделать его более проверяемым?

Question

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

1. Добавление сеттеров только для того, чтобы я мог установить внутренний объект в макет.
2. Добавление геттеров для внутренних карт/списков, чтобы я мог проверить, что внутреннее состояние объекта изменилось после выполнения какого-либо внешнего действия.
3. Обертывание конкретных системных классов и создание нового интерфейса, чтобы я мог их издеваться. Например, классы файлов могут быть сложными для создания флеш-памяти, поэтому я создам новый интерфейс FileInterface и WrappedFile, который расширяет его, а затем использует FileInterface вместо File.

Answer 1

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

Из ваших трех примеров только # 3 действительно хороший; часто эти новые интерфейсы сделают ваш код более гибким для регулярного использования позже. # 1 обычно адресуется для тестирования через инъекцию зависимостей, что, на мой взгляд, делает код излишне сложным, но, по крайней мере, упрощает тестирование. # 2 звучит как плохая идея в целом.

Answer 2

Кажется разумным. Однако некоторые вещи не нуждаются в проверке; Я бы предложил проверить, не добавлено ли добавление в список, немного бесполезно. Но делайте то, с чем вам комфортно.

Answer 3

Это компромисс ..

Вы хотите тонкий, обтекаемой API или раздутой более сложным, но easilier испытано.

Не ответ, который вы хотели бы услышать, я знаю :)

Answer 4

Это прекрасно, и даже рекомендуется, чтобы изменить код, чтобы сделать его более проверяемым. Вот список 10 things that make code hard to test.

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

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

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

Хотя изменение в порядке, лучше всего делать TDD. Он дает проверяемый код естественным образом, как только тесты будут написаны первыми.

Answer 5

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