Набить руку TDD
 

хай всем. обращаюсь к публике за мелкими идеями проектов (супер мелкими), где можно набить руку к подходу Test Driven Development. Т.е. какая-то мелкая задача с техническим описанием, что можно и чего нельзя. Так то оно всё понятно, но когда садишься за реальную задачу, то теряешься как-то...

Пока вот что нашел:
String Calculator

буду рад, если дополнительно ещё что-нибудь посоветуете :)

Забей, это утопия. Никто нигде и некогда не использует TDD, т.к. это квинтэссенция контпродуктивности, а те кто говорит, что использует просто врёт, чтобы повыпендриваться :)

Я бы отнёс TDD к 100% покрытию кода, которое также невозможно в реальной жизни.
Тесты писать нужно, но TDD это перебор :)

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

console.log :cray:

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

Привет!

<label>I'm agree
    <input type="checkbox"/>
</label>
<div style="display: none;">Lisense</div>

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

Кстати, чем концепция TDD отличается от обычного программирования?

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

блина, я уже думал, кончится мучение от проектирования и забывчивости)

то же самое относится и к BDD, полагаю?

мне просто надоело тратить время на сидение в отладчике и "клик-клик" тестинг и я хотел бы этот процесс ускорить


благодарю :)

Долго сидишь? Ню, ню. А то у меня бывает день программа работает, а потом бабах и я узнаю об этом мире что-то новое. Эмулирование теста может занять 1 день :) Я называю это полубоевой сервер. Всплывающие баги просто невозможно предсказать, если не имеешь соответсвующих знаний, которых не может быть при первой встрече с новым багом.

А еще ошибка чаще всего не логируется, т.к. неизвестная :D

Мне думается, что ты добъешся каких-то результатов, вот только мне интересно каких? :D

пока что до упорной практики не дошло, но первые вздохи есть
они все такие ... сначала

Я про логирование. Например браузер падает и ты не знаешь в какой момент, как отлогировать ошибку? Единственный способ, который я знаю - писать в файл. Допустим ты пишешь в файл и написал уже 5 Гб логов :) Главное писать в мелкие файлы, а не в один, тогда можно посмотреть последний, а не пытаться открыть 5 Гб файл. :)

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

Представляю себе веселых финских гугловцев, которые сидят и ржут, - а-ха-ха-ха, мы отсканировали 500 терабайт, и неверно создали линкование, ахаха, теперь это гора неразборного мусора, надо было TDD сделать из 500 машин, хоу-хоу-хоу :)

Так пиши тесты на взаимодействие с GUI. Можно использовать тот же Jasmine или любой другой фреймворк для тестов.

Для автоматизации удобно юзать Karma и PhanthomJS. Тесты запускаются во время отправки коммита и отправка фейлится, если какой либо из тестов провалился.