Как тест-ориентированная разработка и открытый / закрытый принцип работают вместе?

Question

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

Answer 1

Даже если вы согласитесь с тем, что если программное обеспечение работает и не изменяется, вам не нужно его тестировать (что я не делаю), вам все равно нужно показать, что компонент работает в первомместо .Я бы сказал, что одним из лучших способов сделать это является юнит-тест (ы).

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

Помните, что одним из результатов наличия набора тестов является то, что он повышает удобство обслуживания, показываякогда что-то меняется.Поэтому, даже если ваша команда следит за O в SOLID, это не значит, что все не изменится случайно.Таким образом, тесты помогают в этом, показывая, изменилось ли что-то непреднамеренно, и показывают, что именно изменилось.

Answer 2

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

Ну, совсем нет.Откуда вы знаете, что оригинальная, закрытая, реализация верна?

Долгосрочная выгода от дополнительной первоначальной стоимости модульного тестирования потеряна

Важная находка разработки программного обеспеченияЭкономика заключается в том, что гораздо дороже обнаружить и устранить дефект на более позднем этапе эксплуатации продукта.IIRC, примерно на порядок для каждой стадии в классическом процессе развития "водопада".Поскольку юнит-тесты (будь то TDD или первый тест) обнаруживают дефекты на ранней стадии, они могут быстро окупить свои затраты.

он не изменится

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