TDD - При введении класса при рефакторинге - должен ли этот класс быть модульным?

Question

Предположим, у вас есть класс, который проходит все свои текущие модульные тесты.

Если бы вы добавили или извлекли некоторые методы / представили новый класс, а затем использовали композицию для включения той же функциональности, потребовалось бы тестирование нового класса?

Я разрываюсь между тем, стоит ли вам делать это, поэтому любой совет будет отличным.

Edit:

Предположим, мне следовало добавить, что я использую DI (Dependency Injection), поэтому я должен внедрить и новый класс?

Answer 1

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

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

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

Answer 2

Не в контексте TDD, нет, ИМХО. Существующие тесты оправдывают все о существовании класса. Если вам нужно добавить поведение в класс, то самое время ввести тест.

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

РЕДАКТИРОВАТЬ: После вашего редактирования я бы сказал, что это хороший повод для перемещения некоторых существующих тестов (или части существующих тестов). Если класс настолько отделен, что требует инъекции, то кажется, что существующие тесты могут не охватывать его, если они остаются там, где они есть.

Answer 3

Ну да и нет.

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

Теперь вы находитесь в фазе рефакторинга. Вы хотите извлечь код из одного класса и поместить его в свой собственный класс, вероятно, чтобы не отставать от Принципа единой ответственности (или SRP).

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

Однако весьма вероятно, что рефакторинг кода нарушит ваши тесты. Скорее всего, это вызвано хрупкими тестами, которые проверяют поведение, а не состояние - то есть вы высмеяли методы, которые вы портировали.

С другой стороны, если ваши тесты в основном ориентированы на состояние (то есть вы утверждаете результаты и игнорируете реализацию), то ваш новый компонент службы (блок кода, извлеченный в новый класс) не будет тестироваться. Если вы используете какой-либо инструмент тестирования покрытия кода , вы узнаете об этом. Если это так, вы можете проверить, работает ли он. Может , потому что 100% охват кода не желателен и не осуществим. Если возможно, я бы попытался добавить тесты для этой службы.

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

Answer 4

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

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

Answer 5

Я бы сказал нет. Он уже проверяется тестами, запущенными на старом классе.