А вы программируете по TDD?

>Жопой чувствую, что c TDD получим больше проблем, чем решим

В покрытии кода тестами ничего плохого нет. Уверенность в завтрашнем дне, так сказать.

>А вы применяете ТDD? Какой опыт работы с ним?

В чистом виде - очень ограниченно. В процессе разработки основного функционала я не пишу тесты до кода (а надо бы). Пишу их позже, когда кодовая база уже сформировалась и дальше идёт допиливание и полирование. Да и рефакторить без тестов как то страшно

Стараюсь. Не в полном смысле, но ключевые моменты тестами покрываю. А если pair-programming - взаимопроверка - вот это действительно организационный кретинизм.

У нас один тоже толкал Extrime Programming. После общения с ним стало понятно что он ничего о нем не понимает. Как результат, через пару недель про это уже никто не вспоминал, а тесты откинули через нехватку времени :)

А вы применяете ТDD? Какой опыт работы с ним?

применяю, опыт положительный

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

и да, лучший инструмент - это тот который подходит команде

Жопой чувствую, что c TDD получим больше проблем, чем решим.

если правильно применять - действительно лучше станет, но месяцев 4-6 придётся помучиться

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

расслабляйтесь и получайте удовольствие, а если что - баллон катите на менеджера, если всё выйдет плохо его с вами больше не будет, а вы и потащитесь и спасётесь

а тесты откинули через нехватку времени

ой лукавите «мущина», тесты как раз позволяют экономить время, а откидывают их, в первую очередь, любители на досуге поменять очередной раз API - вот уж когда тесты в ногах путаются

Я же ведь не про себя рассказывал. Кто их ввел тот их и откинул ;)

Я же ведь не про себя рассказывал. Кто их ввел тот их и откинул ;)

да я ни на кого пальцем и не показывал :)

Приглашали меня в одну контору, где практиковалось TDD. Сбежал в ужасе.

Менеджер все правильно делает. TDD это хорошо.

А правильнее бы таки писать тесты ДО кода - сразу видел бы многие проектные ошибки и кривой API, исправил бы еще до написания.

Да, я это понимаю. Но обстоятельства складываются иначе :)

Обстоятельства - начальство, которому TDD неугоден?

Можно сказать и так.

Сейчас приоритетнее предоставить рабочий прототип, чем тратить время на написание тестов для ничего. Более того, сами тесты в силу особенностей всей системы в целом были бы весьма нетривиальными - замешанными на хитровыенутой работе с сетью и девайсами.

В прошлый раз вообще пришлось написать свой велосипед даже для такой мелочи, как маленькая библиотека эмуляции :)

> А правильнее бы таки писать тесты ДО кода

Всё правильно, но вот когда программа ворочает сложными взаимозависимыми структурами, да ещё нетривиально взаимодействует с внешним миром, начинается гемор с mocks/stubs и прочим фаулером головного мозга. Это сильно напрягает, особенно когда сроки поджимают (и хочется выкинуть нахер весь этот тест-арт).

> Более того, сами тесты в силу особенностей всей системы в целом были бы весьма нетривиальными - замешанными на хитровыенутой работе с сетью и девайсами

+100

Во время активной разработки тесты только мешаются. Их имеет смысл писать, только когда функциональность фиксированная по своей природе, либо код прошёл фазу утряски.

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

+1

сразу видел бы многие проектные ошибки и кривой API,

Тоже не плохо, но это ваше XP енфорсит bottom-up design. И соответственно TDD помогает выявлять ошибки именно такого проектирования, которое само по себе не есть гуд.

>Похоже, в нашей конторе новая мода появляется - один из менеджеров услышал про TDD (TestDrivenDevelopment) и теперь пытается активно протолкнуть это самое TDD в купе с pair programming.

услышал

протолкнуть

pair programming

больше всего проблем вы получите с этим менеджером. в самом же TDD ничего плохого нет, если правильно его готовить

А если pair-programming - взаимопроверка - вот это действительно организационный кретинизм.

Ага. Сидят Вася и Петя, прожат. Вася хочет проверить вконтакте, Петя - посмотреть порнуху. А они оба молчат и прожат, злые как собаки. И КПД падает от злости и кипящих мозгов, и люди друг друга ненавидеть начинают.

В идеале надо разделять тестировщиков и кодеров, тогда между ними возникает соревновательный процесс, и баги все быстро фиксятся. А писать тесты для своего же кода - это морально тяжело, всегда подсознательно хочется притвориться что все и так нормально работает, и что все баги - это на самом деле фичи.

Более того, сами тесты в силу особенностей всей системы в целом были бы весьма нетривиальными - замешанными на хитровыенутой работе с сетью и девайсами.

just use mocking framework luke

// google mock f.ex.

Сидят Вася и Петя, прожат. Вася хочет проверить вконтакте, Петя - посмотреть порнуху. А они оба молчат и прожат, злые как собаки. И КПД падает...

картина маслом, можно подумать если бы один сидел во вконтакте, а другой смотрел порнуху (это не одно и то же?) КПД бы резко стал over 9k

А писать тесты для своего же кода - это морально тяжело, всегда подсознательно хочется притвориться что все и так нормально работает, и что все баги - это на самом деле фичи.

Поэтому рекомендуют писать не тесты под кода, а код под тесты

man tdd

Их имеет смысл писать, только когда функциональность фиксированная по своей природе, либо код прошёл фазу утряски.

простите, но Вы глубоко заблуждаетесь

Тесты не заменяют проектирование, как бы многим не хотелось казаться. Они лишь его завершают.

и не заменяют и не завершают, просто позволяют избавиться от 90% дебага, причём сделать это весьма эффективно и с большой экономией времени

Обычно их легко написать, когда приложение уже хорошо спроектировано.

бесполезное занятие, эти ваши подгоны решений под ответ

начинается гемор с mocks/stubs

гемор начинается не от фаулера и mock'ов, а от непонимания концепций и отсутствия опыта

удобно если они есть для расчетов, если же много взамодействия со внешним миром то нет.

удобно если они есть для расчетов, если же много взамодействия со внешним миром то нет.

не вижу связи

Мок это затычка. Как я с моком проверю, например, что аудиопоток действительно захватывается с микрофона и проигрывается на получателе корректно?

Как я узнаю, что сервер правильно микширует потоки, поступающие с N клиентов и, соответственно, N устройств?

Поэтому рекомендуют писать не тесты под кода, а код под тесты

При любой очередности лучше разделять тестировщиков и кодеров.

> Во время активной разработки тесты только мешаются.

Двачую этого анонимуса.

Сидят Вася и Петя, прожат. Вася хочет проверить вконтакте, Петя - посмотреть порнуху. А они оба молчат и прожат, злые как собаки. И КПД падает...

картина маслом, можно подумать если бы один сидел во вконтакте, а другой смотрел порнуху (это не одно и то же?) КПД бы резко стал over 9k

Я очень образно. Сидеть 8 часов и прожить очень не каждый может. Надо как-то отвлекаться порой, а при парном такого не выходит.

Еще это менее продуктивно из-за того, что когда уровни программистов разные, то более слабый тормозит более сильного и опять падает производительность.

Да, проблемы получите, множество) Плюшки тоже!)

TDD - это способ мышления, ему нужно учиться. Долго.

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

Большинство наших мобильных приложений на 80% состоят из красивого гуя (а 10% оставшейся логики зависит от гуя напрямую).
Большинство веб-приложений жестко зависят от архитектуры ынтерпрайзного стека, и тут начинаются извращения типа мокнутых сервлетов.

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

Еще минус у TDD для языков, в которых нет автоматических рефакторингов. Это просто ад!

Но пока не нахожу достаточных для аргументации аргументов

1) ты делаешь проверку только один раз. Потом за тебя дебажит машина. Автоматически. Это экономит тыщу миллионов времени.

2) рефакторинг. Без тестов нельзя делать рефакторинг. Если тесты сделаны для покрытия (т.е. не по тдд), то тесты будут рефакториться вместе с кодом, и в результате получится непойми что. Если тесты являются ядром кода, то можно быть спокойным.

3) можно избавиться от бОльшей части документации к коду - тесты и есть документация.

>> Еще это менее продуктивно из-за того, что когда уровни программистов разные, то более слабый тормозит более сильного и опять падает производительность.

Один из плюсов парного программирования адептами xp указывается рост менее опытного программера до уровня более сильного.

Один из плюсов парного программирования адептами xp указывается рост менее опытного программера до уровня более сильного.

Я бы просто не выдержал долго специально тормозить из-за более слабого. Всё время приземлять полёт мысли об асфальт - это печально.

у меня задачи весьма тривиальны, но я, честно признаюсь, ваще не представляю, как их впихнуть в ТДД. До этого момента всегда было примерно так: кодим, части, которые считаю критичными проверяю через Модуль-Тесты и функциональность всей системы целиком через некоторые системные тесты. Т.е. разработка по выше отмеченному принципу:«Во время активной разработки тесты только мешаются. Их имеет смысл писать, только когда функциональность фиксированная по своей природе, либо код прошёл фазу утряски.»
Оговорюсь - работаю в embedded, т.е. все программы крутятся на железе. Конечно, некоторые части и даже некоторые программы можно было бы изначально проектировать через ТДД, но вот конкретный пример: я сейчас пишу программу, которая запускается на железе как инит-процесс линукса и управляет всем железом, т.е. например, получает команду по IPC - выставить яркость экрана, через файл в SYSFS пишет значение яркости, драйвер подхватывает его и выставляет, другое - определение, когда конкретное устройство подключили по УСБ-Хост - я написал udev rule файл, который определяет подключили ли наше внешнее устройство к прибору, если да, то пишет в файл в /tmp соответствующую строку. Моя программа по select() определяет, что ятот файл изменился, парсит и дальше подгружает драйвера, конфигурирует внешнее устройство.
Вот теперь требование от менеджера - ВСЕ программы при commit в svn должны на buildservere запускать тесты (а тесты должны быть написаны, как вы сами знаете, еще до кода) и показывать результат ТДД тестов на сервере. Причем, когда я пытаюсь объяснить ему, что такие тесты сделать на билд-сервере пиздец как сложно (сама программа гораздо проще тестов получается) мне доказывают, что только ленивый программист не работает по ТДД (ну так в презентации написано ;-))) ). И я даже не знаю, что делать. Причем навязывают еще одного «разработчика» в пару - вчерашнего студента. Я видел мельком его код. Ладно я не идеален, но это - просто атас :)

>3) можно избавиться от бОльшей части документации к коду - тесты и есть документация.

Документация - ваще отдельная тема. Нам без документации никак нельзя - в мед. приборах документация нужна на фазе сертификации. Раньше писали доки в Ворде, а вот сейчас - новая мода - UML. Рисуем диаграммки в EnterpriseArchitect :)

> ты делаешь проверку только один раз. Потом за тебя дебажит машина. Автоматически. Это экономит тыщу миллионов времени.

Program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence.

Dijkstra, Edsger W. Dijkstra.

Как я с моком проверю, например, что аудиопоток действительно захватывается с микрофона и проигрывается на получателе корректно?

Как я узнаю, что сервер правильно микширует потоки, поступающие с N клиентов и, соответственно, N устройств?

последовательно, и не надо путать интеграционное тестирование с модульным

> Поэтому рекомендуют писать не тесты под кода, а код под тесты

При любой очередности лучше разделять тестировщиков и кодеров.

нет, это не так

Надо как-то отвлекаться порой, а при парном такого не выходит.

да не надо все 40 часов в неделю изображать тамару и санитара, провели штурм и разбежались, если надоело, а дело ещё надо работать - сходили кофе попили, перекусили чего

у меня задачи весьма тривиальны, но я, честно признаюсь, ваще не представляю, как их впихнуть в ТДД.

и в этом проблема

Вот теперь требование от менеджера - ВСЕ программы при commit в svn должны на buildservere запускать тесты (а тесты должны быть написаны, как вы сами знаете, еще до кода) и показывать результат ТДД тестов на сервере. Причем, когда я пытаюсь объяснить ему, что такие тесты сделать на билд-сервере пиздец как сложно (сама программа гораздо проще тестов получается) мне доказывают, что только ленивый программист не работает по ТДД (ну так в презентации написано ;-))) ). И я даже не знаю, что делать.

скажи ему, что нельзя объять необъятное и запихнуть незапихуемое

>последовательно, и не надо путать интеграционное тестирование с модульным

Во первых, никто не путает, во вторых, это не отвергает хитровыебутость всех тестов в целом и неоправданные временные затраты на них в начале пути.

>последовательно, и не надо путать интеграционное тестирование с модульным

Во первых, никто не путает

Ваши слова, о благородный дон, говорят об обратном

это не отвергает хитровыебутость всех тестов в целом

тесты - не мандавошки, как их сделаешь/расставишь и так они и будут стоять

и неоправданные временные затраты на них в начале пути

ты никогда ничего до конца не доделываешь?

простите, но Вы глубоко заблуждаетесь

Что тестировать, если программер отправлен в свободное плавание? И он пишет на языке с полноценным REPL и ультрапоздним связыванием, поэтому не только код рождается на кончиках пальцев, но и вообще сама архитектура.

>Ваши слова, о благородный дон, говорят об обратном

Можешь думать, что хочешь

тесты - не мандавошки, как их сделаешь/расставишь и так они и будут стоять

Спасибо, кэп. Но видеоконференцию действительно проще протестировать ручками, чем бороться с ветрянными мельницами и решать проблемы, придуманные себе самим.

ты никогда ничего до конца не доделываешь?

Конца не существует, как и предела совершенству :3