#unit-testing #tdd #solid-principles #open-closed-principle
#модульное тестирование #tdd #solid-принципы #принцип open-closed
Вопрос:
Я читал о модульном тестировании, TDD и принципах SOLID, и мне нужны некоторые разъяснения. Я понимаю, что если придерживаться принципа open / closed, модульное тестирование может стать в значительной степени ненужным из-за того, что код закрыт для модификации — таким образом, нет необходимости повторно тестировать, если код правильно изолирован и развязан. Долгосрочная выгода от дополнительных первоначальных затрат на модульное тестирование теряется, если после прохождения соответствующих модульных тестов код не изменится. Код всегда будет проходить, потому что он никогда не изменится, верно? Унаследованные классы необходимо будет протестировать, но как только они пройдут соответствующие тесты, они тоже будут закрыты для модификации и не нуждаются в повторном тестировании. Статья в Википедии об OCP подкрепляет эту мысль в первом абзаце (я понимаю, что это не делает это законом).
Лучшее объяснение, которое я нашел для OCP и TDD, живущих в гармонии, находится здесь, хотя, похоже, Арнон говорит, что OCP дополняет TDD тем, что разработчику не рекомендуется изменять исходный код, потому что существующие методы тестирования могут стать сложными при изменении для тестирования новой функциональности.
И это все, что нужно? Имейте в виду, что я не ищу аргументов, я новичок в этом, и я ищу разъяснений у тех, у кого больше опыта в этом вопросе, чем у меня.
Ответ №1:
Даже если вы согласитесь с тем, что когда программное обеспечение работает и не меняется, вам не нужно его тестировать (чего я не делаю), вам все равно нужно показать, что компонент работает в первую очередь. Я бы сказал, что одним из лучших способов сделать это является модульный тест (ы).
Кроме того, практически говоря, как только у вас есть тест, его запуск обходится очень дешево. Таким образом, даже если компоненты не меняются, вы не теряете много, постоянно выполняя тесты. Кроме того, иногда дизайн меняется, и вам нужно вернуться и переделать некоторые компоненты — наличие модульных тестов определенно помогает в этом случае…
Помните, что одним из результатов наличия набора тестов является то, что он повышает удобство обслуживания, показывая, когда что-то меняется. Так что, даже если ваша команда придерживается O в SOLID, это не значит, что все не изменится случайно. Таким образом, тесты помогают в этом, показывая, если что-то было изменено непреднамеренно, и они показывают вам, на что именно повлияло изменение.
Комментарии:
1. Всегда помните, что SOLID — это лучшая практика, а не закон физики, от которого зависит гармоничный баланс вселенной; правила SOLID можно легко нарушить. Даже при неукоснительном соблюдении НАДЕЖНЫЙ дизайн просто не может быть закрыт для всех возможных изменений; закрывая один тип изменений, вы часто делаете другой тип изменений более вероятным и / или более сложным.
Ответ №2:
модульное тестирование может стать в значительной степени ненужным из-за того, что код закрыт для модификации
Ну, совсем нет. Откуда вы знаете, что исходная, закрытая реализация верна?
Теряется долгосрочная выгода от дополнительных первоначальных затрат на модульное тестирование
Важным выводом экономики разработки программного обеспечения является то, что обнаружение и исправление дефекта на более поздних этапах жизненного цикла продукта обходится гораздо дороже. IIRC, примерно на порядок для каждого этапа в классическом «водопадном» процессе разработки. Поскольку модульные тесты (будь то TDD или test-first) обнаруживают дефекты на ранней стадии, они могут быстро окупить свои затраты.
это не изменится
Если в нем есть дефект, его нужно будет изменить. Конечно, если вы можете гарантировать, что ваш код не содержит дефектов, то то, что вы говорите, правда. Но если вы можете гарантировать, что вам не нужно никакого тестирования. Но очень немногие программные проекты могут сделать такое заявление.