TDD - При представлении класса при рефакторинге - что класс должен быть протестированной единицей?
Вы также можете указать имена в результате выполнения команды поиска:
zip name.zip `find . -name <name> -print`
Это особенность используемой оболочки. Вы можете искать "backticks", чтобы определить, как ваша оболочка справляется с этим.
5 ответов
Не в контексте TDD, нет, ИМХО. Существующие тесты подтверждают все о существовании класса. Если вам нужно добавить поведение к классу, самое время ввести тест.
При этом, как говорится, это может сделать ваш код и тесты более понятными, чтобы переместить тесты в класс, который относится к новому классу, который вы создали . Это во многом зависит от конкретного случая.
РЕДАКТИРОВАТЬ: После вашего редактирования я бы сказал, что это хороший случай для перемещения некоторых существующих тестов (или части существующих тестов). Если класс настолько разделен, что требует внедрения, то похоже, что существующие тесты могут не покрывать его, если они останутся там, где они есть.
Изначально нет, в них нет необходимости. Если бы у вас было идеальное покрытие, вы извлекли класс и больше ничего не сделали, у вас все равно было бы идеальное покрытие (и эти тесты подтвердили бы, что извлечение действительно было чистым рефакторингом).
Но в конечном итоге - и, вероятно, скоро - да. Извлеченный класс, вероятно, будет использоваться за пределами своего исходного контекста, и вы хотите ограничить его поведение с помощью тестов, специфичных для нового класса, чтобы изменения для нового контекста не повлияли непреднамеренно на поведение исходного вызывающего. Конечно, оригинальные тесты все равно это выявят, но хорошие модульные тесты указывают прямо на проблемный модуль,
Я бы сказал нет. Он уже проходит тестирование в старом классе.
Что ж, да и нет.
Если я правильно понимаю, вы написали тесты, и написали производственный код, который обеспечивает прохождение тестов - то есть самое простое, что работает.
Теперь вы находитесь на этапе рефакторинга. Вы хотите извлечь код из одного класса и поместить его в отдельный класс, вероятно, чтобы не отставать от Принципа единой ответственности (или SRP).
Вы можете провести рефакторинг без добавление тестов, так как ваши тесты существуют именно для того, чтобы вы могли без опасений рефакторировать. Помните - рефакторинг означает изменение кода без изменения функциональности.
Однако вполне вероятно, что рефакторинг кода нарушит ваши тесты. Скорее всего, это вызвано хрупкими тестами, которые проверяют поведение, а не состояние, т.е. вы высмеивали перенесенные вами методы.
С другой стороны, если ваши тесты в основном управляются состоянием (т. е. вы утверждаете результаты и игнорируете реализацию), то ваш новый компонент службы (блок кода, который вы извлекли в новый класс) не будут проверяться. Если вы воспользуетесь какой-либо формой инструмента тестирования покрытия кода , вы узнаете. Если это так, вы можете проверить, что это работает. Может быть , потому что 100% покрытие кода нежелательно и нецелесообразно. Если возможно, я бы попытался добавить тесты для этой службы.
В конце концов, это вполне может сводиться к вынесению суждения.
тогда ваш новый служебный компонент (блок кода, который вы извлекли в новый класс) не будет протестирован. Если вы воспользуетесь какой-либо формой инструмента тестирования покрытия кода , вы узнаете. Если это так, вы можете проверить, что это работает. Может быть , потому что 100% покрытие кода нежелательно и нецелесообразно. Если возможно, я бы попытался добавить тесты для этой службы.В конце концов, это вполне может сводиться к вынесению суждения.
тогда ваш новый служебный компонент (блок кода, который вы извлекли в новый класс) не будет протестирован. Если вы воспользуетесь какой-либо формой инструмента тестирования покрытия кода , вы узнаете. Если это так, вы можете проверить, что это работает. Может быть , потому что 100% покрытие кода нежелательно и нецелесообразно. Если возможно, я бы попытался добавить тесты для этой службы.В конце концов, это вполне может сводиться к вынесению суждения.
Как говорили другие, вероятно, это не совсем нужно сразу, поскольку все то же самое все еще тестируется. Но как только вы начнете вносить изменения в любой из этих двух классов по отдельности, вам следует разделить тесты.
Конечно, тесты не должны быть слишком сложными; поскольку у вас уже есть тестируемый материал, разбить различные части тестов будет довольно просто.