tag:blogger.com,1999:blog-5092972944722879737.post8529779831295277184..comments2023-06-06T13:29:57.630+03:00Comments on Stump's Workshop: TDD Anti-patterns от Джеймса КарраSergey Rozovikhttp://www.blogger.com/profile/13717493609449785600noreply@blogger.comBlogger5125tag:blogger.com,1999:blog-5092972944722879737.post-35851192672701504702008-01-23T14:13:00.000+03:002008-01-23T14:13:00.000+03:00to IvРад стараться :)to Iv<BR/><BR/>Рад стараться :)Sergey Rozovikhttps://www.blogger.com/profile/13717493609449785600noreply@blogger.comtag:blogger.com,1999:blog-5092972944722879737.post-7565201416194627082008-01-23T14:04:00.000+03:002008-01-23T14:04:00.000+03:00Отлично, спасибо за статью.Отлично, спасибо за статью.Ivhttps://www.blogger.com/profile/09724511625118329123noreply@blogger.comtag:blogger.com,1999:blog-5092972944722879737.post-71807815267668474572008-01-22T17:41:00.000+03:002008-01-22T17:41:00.000+03:00to Elena Makurochkina>но появление бэбика абсолют...<B>to Elena Makurochkina</B><BR/>>но появление бэбика абсолютно выбило из колеи и довести текст до читаемого состояния так и не успела. <BR/><BR/>Поздравляю! Растите большие и здоровые! :))Sergey Rozovikhttps://www.blogger.com/profile/13717493609449785600noreply@blogger.comtag:blogger.com,1999:blog-5092972944722879737.post-43855475552420332192008-01-22T17:37:00.000+03:002008-01-22T17:37:00.000+03:00Карр явно указывает, почему он занес "Инспектор" в...Карр явно указывает, почему он занес "Инспектор" в анти-патерны: он существенно затрудняет рефакторинг тестируемого класса. Это давняя дискуссия - могут ли и должны ли модульные тесты нарушать инкапсуляцию тестируемых классов. Я считаю что нет. Тесты должны тестировать внешний интерфейс классов, на то он и ООП, чтоб скрывать (инкапсулировать) внутреннюю логику объектов. Что касается описанного вами, Елена, случая, то тут надо рефакторить дизайн тестируемого модуля. Удобство тестирования это один из аспектов, которые следует учитывать при дизайне.<BR/><BR/>Второй поинт. Большой объем настроек для тестового окружения - тоже известная проблема. И она порождает соблазн построить единый тестовый набор данных для всех тестов или использовать выходные данные одного теста на входе другого. Увы решая одни проблеммы мы таким образом множим другие. Атомарность и независимость модульных тестов - это фундаментальный принцип, который мы нарушаем. Это порождает массу проблем и результат - тесты становится очень сложно поддерживать, их забрасывают и остаются вовсе без тестов.Sergey Rozovikhttps://www.blogger.com/profile/13717493609449785600noreply@blogger.comtag:blogger.com,1999:blog-5092972944722879737.post-62794326963144070032008-01-22T16:44:00.000+03:002008-01-22T16:44:00.000+03:00Согласна почти со всем, кроме...Абсолютно не согла...Согласна почти со всем, кроме...<BR/><BR/>Абсолютно не согласна с занесением <B>The Inspector</B> в ошибки тестирования. И именно детальное тестирование отдельных внутренних функций упрощает (а не усложняет) в дальнейшем как рефакторинг, так и доработку и изменение логики поведения классов (иногда это требуется). Не единожды проверена на собственном опыте полезность детальных тестов приватных функций и классов. И очень сильно ощущается нужность таких тестов, когда они нужны, но их нет (например, когда наружу торчит класс с парой функций, за которым скрывается громадная подсистема, а оттестировано это все как черный ящик и если при изменениях какой-то тест не проходит, то для того, что бы понять почему приходится перерывать массу кода).<BR/><BR/>Еще бывают полезны <B> Hidden Dependency</B>. Это хороший способ избавления от <B> The Giant + Excessive Setup = The Slow Poke</B>. Когда реально для моделирования ситуации требуется большой объем настройки тестового окружения. Если разносить все в отдельные тесты, где окружение настраивается каждый раз заново (и каждый раз с большим количеством проверок самих настроек), то тесты становятся большими, слабочитаемыми и слабоконтролируемыми, и обычно медленными в исполнении. Рецепт: выделить набор тестов в отдельный тестовый блок, где они всегда выполняются в нужной последовательности, единожды настроить окружение и в каждом следующем тесте использовать результаты предыдущего.<BR/><BR/>А вообще залог успеха, причем не только в тестировании, делать все не по шаблону, а исходя из нужд проекта.<BR/><BR/>PS: У меня недописанный пост по тестированию (юнит и функциональные тесты) с начала лета лежит, но появление бэбика абсолютно выбило из колеи и довести текст до читаемого состояния так и не успела. Надеюсь в обозримом будущем появятся силы на блог.Elena Makurochkinahttps://www.blogger.com/profile/15475010538528973275noreply@blogger.com