Я читал о модульном тестировании, TDD и принципах SOLID, и мне нужны некоторые пояснения. Я понимаю, что если придерживаться принципа открытого / закрытого, модульное тестирование может стать в значительной степени ненужным из-за того, что код закрыт для модификации - таким образом, нет необходимости повторно тестировать, если код должным образом изолирован и развязан. Долгосрочная выгода от дополнительных начальных затрат на модульное тестирование теряется, если после прохождения кода соответствующих модульных тестов он не изменится. Код всегда будет проходить, потому что он никогда не изменится, верно? Унаследованные классы необходимо будет протестировать, но как только они пройдут соответствующие тесты, они также будут закрыты для модификации, и их не нужно будет повторно тестировать. Статья в Википедии об OCP усиливает эту мысль в первом абзаце (я понимаю, что не делает это законом).
Лучшее объяснение, которое я нашел для OCP и TDD, живущих в гармонии здесь, хотя кажется, что Арнон говорит, что OCP дополняет TDD тем, что разработчик не рекомендуется изменять исходный код, потому что существующие методы тестирования могут стать сложными при изменении для проверки новых функций.
Это все, что нужно для этого? Имейте в виду, что я не ищу аргументов, я новичок в этом, и я ищу разъяснений от тех, у кого больше опыта в этой теме, чем у меня.
Как работают вместе разработка через тестирование и принцип открытости / закрытости?
Ответы (2)
Даже если вы согласились с тем, что если программа работает и не меняется, вам не нужно ее тестировать (чего я не делаю), вам все равно нужно показать, что компонент в первую очередь работает . Я бы сказал, что один из лучших способов сделать это - это модульные тесты.
Кроме того, практически говоря, если у вас есть тест, его запуск стоит очень мало. Таким образом, даже если компоненты не меняются, вы не потеряете много, постоянно выполняя тесты. Кроме того, иногда дизайн меняется, и вам нужно вернуться и переделать некоторые компоненты - в этом случае определенно помогает модульное тестирование ...
Помните, что одним из результатов наличия набора тестов является то, что он способствует удобству обслуживания, показывая, когда что-то меняется. Так что даже если ваша команда следует букве O в SOLID, это не значит, что ничего не изменится случайно. Таким образом, тесты помогают в этом, показывая, было ли что-то изменено непреднамеренно, и показывают, что именно было затронуто этим изменением.
модульное тестирование может стать в значительной степени ненужным из-за того, что код закрыт для модификации
Ну совсем нет. Как узнать, что исходная закрытая реализация верна?
Долгосрочная выгода от добавленных авансовых затрат на модульное тестирование теряется.
Важным выводом экономики программной инженерии является то, что обнаружение и исправление дефекта на более позднем этапе жизненного цикла продукта обходится гораздо дороже. IIRC, примерно на порядок для каждого этапа классического «водопадного» процесса разработки. Поскольку модульные тесты (будь то TDD или test-first) обнаруживают дефекты на ранней стадии, они могут быстро окупить свои затраты.
это не изменится
Если в нем есть дефект, его придется заменить. Конечно, если вы можете гарантировать, что ваш код не содержит дефектов, то то, что вы говорите, верно. Но если вы можете гарантировать, что вам не нужно какое-либо тестирование. Но очень немногие программные проекты могут сделать такое заявление.
