Найдутся! В смысле — уже нашлись :) Пишите, пожалуйста, еще. Мавен — это инструмент, и им, как и любым инструментом, хочется «просто пользоваться» не затрачивая массу усилий на то что б понять, как же эту хреновину уже заставить работать и перейти к тем проблемам, из-за которых все тут собрались — собственно к программированию.
В условиях задачи было «поддерживать кучу тестов тоже напряжно», что подразумевает изменение поведения. Если эти сеттеры и геттеры начинают менять поведение, то на них и правда нужно писать тесты и это уже далеко не просто сеттеры и геттеры.
Если Сипуление коварно возвращает объекты ошибок, то не ваша ли задача скрыть это от вашего пользователя? Возьмите эти ошибки, превратите в нормальные исключения — пусть ваш API будет хорошим. Почему все остальные должны мучаться?
Я ж сказал «например». Может быть все, что угодно же. А «взять ошибки и превратить в нормальные исключения» — это хорошо, но мало что меняет. Беда остается на своем месте — во время написания теста по TDD ты не знаешь, что у тебя буквально тут же возникнет совершенно левая задача по конвертации ошибок в исключения, без реализации которой ты не сможешь приступить к той задаче, к которой хотел. Готово дело — сроки поплыли… :)
Если «поддерживать кучу тестов напряжно», то это значит, что они ломаются, иначе бы не напрягало. Если они ломаются, то значит вы изменили старое поведение на новое. А если вы изменили поведение, но не стали отражать этого в тестах, то в следующий раз сломаются уже не тесты (которых нет), а код на продакшене. Зачем это надо?
Насчёт сторонних библиотек — TDD тут тоже хорошо подходит. Ты пишешь тест на свой код, который использует библиотеку X. Запускаешь тест и видишь, как эта библиотека ведёт себя. Это ведь гораздо эффективнее, чем экспериментировать с этой библиотекой на живом коде, где после каждого изменения нужно рестартовать/редеплоить/логиниться/и пр.
Нет, я имел ввиду другое. Я реализую класс Сипулька. По TDD я должен сначала написать на Сипульку тесты — пишу. Красивое апи, возвращающее то, что мне надо. Начинаю реализовывать Сипульку, и в какой-то момент использую библиотеку Сипуление. И тут выясняется, что эта библиотека коварно… ну, не знаю… возвращает объекты ошибок вместо того, что бы кидать исключения, что очень и очень плохо ложится в то апи, которое я заложил в тесте. Переосмысляю, и иду переписывать тест с нуля. Смыть, повторить. Такие натыкания на «неожиданное поведение» могут быть постоянными и болезненными, они будут отбрасывать к началу, и так до тех пор, пока инструмент не будет изучен до того уровня, который позволит писать тесты с учетом подводных камней. Это больно! Это тем более больно, если такой источник не очевидного поведения закопан глубоко в кишках реализации. TLD в данном случае эту боль сократит за счет отсутствия тяни-толкая, проблемы будут решаться по мере возникновения, а тестами покроется «то, что выросло», которое потом придется рефакторить.
Отчасти тут спасут «учебные тесты», но этому же тоже нужно учить :)
Это ведь гораздо эффективнее, чем экспериментировать с этой библиотекой на живом коде, где после каждого изменения нужно рестартовать/редеплоить/логиниться/и пр.
Дядя Боб предлагает использовать для этого учебные тесты. Пробовал — и правда помогает!
По-моему, такой вывод в диалоге как раз-таки прозвучал!
Если я правильно помню, то звучало что-то вроде «при TDD налететь на эти грабли гораздо проще», что по-моему не так. Возможно я не внимательно прочитал.
Что же, по-Вашему, самое интересное в этой теме?
Как это что? :) Конечно же применимость и крайние случаи!
Например, по моим самоощущениям TDD очень требователен к уровню программиста. Когда пишется тест на свой ванильный класс без примесей — это одно, но когда в нем задействована какая-то сторонняя библиотека, то написать грамотный тест получится только имея хорошие знания о том, как эта библиотека повлияет на результат. При TLD приходится проще — знания в этой библиотеке во-первых приобретаются по ходу кодинга, а во-вторых можно ограничится только тем, что реально понадобилось. Можно эту тему обсудить? Будет полезно? Наверное да. Но не дошли.
Так же у любой методологии всегда есть крайние случаи, при которых она начинает больше вредить, чем помогать. Хотелось дискуссии о том, как определять эту тонкую красную линию что бы вовремя сказать себе «стоп, ты загоняешься». Но опять же не случилось.
В общем собеседники на мой вкус зависли на совершенно не принципиальных вещах так и не добравшись до мякоти вопроса, но это тольк мое мнение.
Спасибо! Сам делаю примерно так же, но периодически натыкаюсь на поборников чтрогой чистоты кода, которые начинают ныть «А почему этот метод не приватный? А почему остальные приватные? А давай как-то так, что бы однообразно было?», и начинаааается… =(
Писать тест на приватные методы — очень даже неплохая мысль. Ничего, что они постоянно меняются. Тесты как раз будут помогать их менять. Приватные методы — это тоже API, пусть невидимый снаружи. Это API для самого важного человека во вселенной — для тебя! :) Он тоже должен быть удобным.
Тут возникает два вопроса:
Первый совершенно практического свойства — как лучше всего по вашему мнению покрывать приватные методы? Вопрос задаю с точки зрения суровой практики, просто что б не изобретать велосипед. Как удобнее и лучше это делать?
Второй уже больше теоретический — если хочется протестировать что-то приватное, то это разве не прямой сигнал, что пока выделять этот кусок в отдельный класс со своим апи, которое тоже покрывать тестами?
При прочтении бровь изумленно улетела вверх на том моменте, когда начали подсчитывать количество нажатых клавиш. Мне всегда казалось, что этот показатель сродни LOC, который сильно колеблется от программиста к программисту просто из-за разного code style. К примеру, кто-то сразу придумывает говорящее название метода и параметров, а кто-то сначала делает «рыбу» метода обращая внимание только на сигнатуру, и только потом размышляет над названиями — количество нажатий совершенно разное, а результат в общем-то один. Эрго — этот показатель совершенно не показателен, а значит и говорить о нем не стоит.
Вторая бровь улетела вверх на обсуждении «не все учел, поэтому пришлось начинать сначала». Как мне кажется «не все учесть» можно как при написании кода по TDD, так и без оного. Шансы начать писать код, уткнуться в некую проблему, осознать, что выбранный подход не стреляет, откатится назад и решить задачу по-другому, примерно одинаковы, как при работе по TDD, так и без него.
В общем до самого интересного так и не дошли, к сожалению.
Вы не правы. Я зашел на суйт Матрешки и тоже не понял что это за фреймворк и для чего он нужен, поскольку информативность сайта близка к нулю:
Реактивный API, позволяющий эффективно решать сложные и запутанные задачи
Какие задачи? Это главный вопрос — для чего пригоден, а для чего не пригоден Ваш фреймворк. Ответа процитированное не дает.
Меньше ошибок в коде
Меньше по сравнению с чем? И почему меньше, за счет чего? За счет богатой библиотеки? Или за счет сокращения количества кода, который приходится писать? Или еще почему-то? Нет ответа.
Возможность рефакторинга легаси приложений, без переписывания с нуля
Эта возможность есть всегда и везде, вопрос готовы ли мы платить за это временем и нервами. Тут явно подразумевается, что с Матрешкой боли будет меньше, но почему и за счет чего совершенно не ясно.
Освоить фреймворк можно за пару часов благодаря отсутствию сложных концепций
Поверим на слово. Но как насчет возможностей? Если цена простоты отсутствие возможностей, то зачем такой фреймворк нужен? А о возможностях мы до сих пор ничего не знаем…
Одна из самых удобных документаций среди JavaScript библиотек
А вот это уже претензия на исключительность, которую придется оправдать, иначе впечатление будет загублено окончательно. Вы уверены, что не выдаете желаемое за действительное?
Я имел ввиду, что «тогда» возможности для тестирования всего и вся были куда более ограниченны, нежели сейчас, а так как и сейчас безбажная миграция/интеграция является скорее светлой мечтой, нежели обычным вторником, то говорить, что «тестирование влияния этого программного модуля в случае отказа на работоспособность всей системы в целом не проводилось», наверное, слишком самонадеянно. А может и не самонадеянно, черт его знает, кто там на чем решил сэкономить…
Или код — монолитное сильно связанное
говноговно…Вот до этого в заглавной статье и не дошли :)
Я ж сказал «например». Может быть все, что угодно же. А «взять ошибки и превратить в нормальные исключения» — это хорошо, но мало что меняет. Беда остается на своем месте — во время написания теста по TDD ты не знаешь, что у тебя буквально тут же возникнет совершенно левая задача по конвертации ошибок в исключения, без реализации которой ты не сможешь приступить к той задаче, к которой хотел. Готово дело — сроки поплыли… :)
А вот уволоку ка я это себе :)
Нет, я имел ввиду другое. Я реализую класс Сипулька. По TDD я должен сначала написать на Сипульку тесты — пишу. Красивое апи, возвращающее то, что мне надо. Начинаю реализовывать Сипульку, и в какой-то момент использую библиотеку Сипуление. И тут выясняется, что эта библиотека коварно… ну, не знаю… возвращает объекты ошибок вместо того, что бы кидать исключения, что очень и очень плохо ложится в то апи, которое я заложил в тесте. Переосмысляю, и иду переписывать тест с нуля. Смыть, повторить. Такие натыкания на «неожиданное поведение» могут быть постоянными и болезненными, они будут отбрасывать к началу, и так до тех пор, пока инструмент не будет изучен до того уровня, который позволит писать тесты с учетом подводных камней. Это больно! Это тем более больно, если такой источник не очевидного поведения закопан глубоко в кишках реализации. TLD в данном случае эту боль сократит за счет отсутствия тяни-толкая, проблемы будут решаться по мере возникновения, а тестами покроется «то, что выросло», которое потом придется рефакторить.
Отчасти тут спасут «учебные тесты», но этому же тоже нужно учить :)
Дядя Боб предлагает использовать для этого учебные тесты. Пробовал — и правда помогает!
Если я правильно помню, то звучало что-то вроде «при TDD налететь на эти грабли гораздо проще», что по-моему не так. Возможно я не внимательно прочитал.
Как это что? :) Конечно же применимость и крайние случаи!
Например, по моим самоощущениям TDD очень требователен к уровню программиста. Когда пишется тест на свой ванильный класс без примесей — это одно, но когда в нем задействована какая-то сторонняя библиотека, то написать грамотный тест получится только имея хорошие знания о том, как эта библиотека повлияет на результат. При TLD приходится проще — знания в этой библиотеке во-первых приобретаются по ходу кодинга, а во-вторых можно ограничится только тем, что реально понадобилось. Можно эту тему обсудить? Будет полезно? Наверное да. Но не дошли.
Так же у любой методологии всегда есть крайние случаи, при которых она начинает больше вредить, чем помогать. Хотелось дискуссии о том, как определять эту тонкую красную линию что бы вовремя сказать себе «стоп, ты загоняешься». Но опять же не случилось.
В общем собеседники на мой вкус зависли на совершенно не принципиальных вещах так и не добравшись до мякоти вопроса, но это тольк мое мнение.
Тут возникает два вопроса:
Первый совершенно практического свойства — как лучше всего по вашему мнению покрывать приватные методы? Вопрос задаю с точки зрения суровой практики, просто что б не изобретать велосипед. Как удобнее и лучше это делать?
Второй уже больше теоретический — если хочется протестировать что-то приватное, то это разве не прямой сигнал, что пока выделять этот кусок в отдельный класс со своим апи, которое тоже покрывать тестами?
Вторая бровь улетела вверх на обсуждении «не все учел, поэтому пришлось начинать сначала». Как мне кажется «не все учесть» можно как при написании кода по TDD, так и без оного. Шансы начать писать код, уткнуться в некую проблему, осознать, что выбранный подход не стреляет, откатится назад и решить задачу по-другому, примерно одинаковы, как при работе по TDD, так и без него.
В общем до самого интересного так и не дошли, к сожалению.
Какие задачи? Это главный вопрос — для чего пригоден, а для чего не пригоден Ваш фреймворк. Ответа процитированное не дает.
Меньше по сравнению с чем? И почему меньше, за счет чего? За счет богатой библиотеки? Или за счет сокращения количества кода, который приходится писать? Или еще почему-то? Нет ответа.
Эта возможность есть всегда и везде, вопрос готовы ли мы платить за это временем и нервами. Тут явно подразумевается, что с Матрешкой боли будет меньше, но почему и за счет чего совершенно не ясно.
Поверим на слово. Но как насчет возможностей? Если цена простоты отсутствие возможностей, то зачем такой фреймворк нужен? А о возможностях мы до сих пор ничего не знаем…
А вот это уже претензия на исключительность, которую придется оправдать, иначе впечатление будет загублено окончательно. Вы уверены, что не выдаете желаемое за действительное?