Кодекс, который не подвергается сомнению, действительно меня раздражает. Следующие вещи делают неопровержимый код:
Есть ли еще предупреждающие знаки?
См. следующее сообщение в блоге: Miško Hevery: Как написать 3v1L, нестационарный код.
Ни одна из этих вещей не делает код неустойчивым. Они могут усложнить поиск ошибок на кромках, но при условии, что вы полностью определили критерии успеха для тестирования (и это облегчает тестовую разработку), все, что вам нужно сделать, это передать критерии.
TDD может применяться к поведению конкретных частей, а также к проекту в целом, поэтому вы можете легко протестировать очень маленькие компоненты. Но это означало проверить результаты, а не средства, с помощью которых эти результаты были получены.
При условии, что тесты пройдены, вы выполнили требования. Если после этого есть ошибки, это проблема с тестами, а не с тестируемым кодом (в этом случае тесты должны быть изменены, чтобы уловить ранее непредвиденную проблему).
Вам не все равно (с точки зрения доставки функциональности), есть ли инструкция while в одном из ваших конструкторов. Вы должны спросить себя, что требует бизнес-требование? Я сильно сомневаюсь, что ваш клиент предоставит список требований, включая "наследование, ограниченное 4 уровнями". В качестве требования они могут перечислить "без ошибок", но вам придется обсудить их на следующем: -).
Жестко закодированные зависимости.
Работа в классах GUI, не имеющая ничего общего с презентацией. GUI должен быть полностью отделен от базовой модели.
Код не тестируется, если вы не можете его изменить. Если у вас есть возможность реорганизовать проект, ни один из них не является неустойчивым. Обычно для облегчения тестирования необходимы только очень небольшие модификации. И они могут быть оправданы, потому что они повышают качество кода.
Даже в тех случаях, когда вы описываете, код не обязательно является непроверенным. Это еще труднее проверить. Например, проще проверить код, если вы можете изолировать доступ к базе данных и избегать их во время модульных тестов. Но если вам нужно, вы можете создать базу данных, предназначенную для запуска ваших тестов.
Я бы сказал, что ни одна из этих вещей не делает код неустойчивым. Они затрудняют тестирование модулей, поскольку каждый из них увеличивает сцепление в вашей реализации.
Среди других неприятностей, затрудняющих модульное тестирование:
В целом, любая рекомендация, которую вы можете услышать о создании лучшего кода, также является рекомендацией для упрощения кода unit test.
Базы данных! Особенно те, у кого есть триггеры!
Я знаю, что вы можете издеваться над базой данных, но я всегда обнаружил, что большинство ошибок в моем коде (в основном CRUD-приложения) - это проблемы с данными/сопоставлением, и если вы издеваетесь над базой данных, вы не найдете такого рода ошибка.
Руководство Miško Hevery на Написание тестового кода детализирует недостатки, которые делают код сложным для тестирования. Его список частично совпадает с вашим, но идет в невероятную детализацию.
отсутствие слоев, избыток связи... т.е. класс Y был написан, чтобы знать о X, но он не должен, X является многоразовым. Между тестируемостью и повторным использованием существует сильная взаимосвязь.