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