to post messages and comments.

skillsmatter.com — BDD + DDD или как, общаясь с заказчиком, перенести знания из предметной области в код. При кодировании этих знаний вы можете обнаружить, что каких-то понятий не хватает. Это нормально. Продолжайте общаться с заказчиком, задавайте уточняющие вопросы. Главное, не сводите это общение к обсуждению UI.

Биллинг. В прошлом году оборот составил около $300 000. Из них 1.5% он спиздил у пользователей. Я спиздил у пользователей. Потому что не писал тесты, блядь. Всё, второй работы не будет, будут книги по bdd и бессонные ночи.

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

жуец, пощупал сегодня travis-ci.org
что сказать? это очень няшный инструмент для continuous integration
в комплекте с simplecov — убойный инструмент для диагностики "а не поломал ли чего-нибудь мой коммит".

жуечка, я тут обнаружил, что под ruby 1.9 и рельсы 3.2 отлично ложится simplecov. прекрасный, просто прекрасный гем, показывающий процент покрытия тестами твоего кода!

А в каком месте bdd-цикла рисуются макеты интерфейса? Я нихрена не представляю как оно должно выглядеть. Отсюда вся неопределённость. Мне рисовать что ли? >_>

bdd

Взял и отложил написание тестов на потом >_> Хочется сначала накодить каркас чтобы быстро получить понимание того, как всё должно быть.

Где я не с той стороны зашёл?

Два (или три?) часа назад сел чтобы реализовать кусок кода по всем канонам BDD. Написал каркас клёвого класса, тесты, описал несколько тестов, добавил функционал, поправил. Подумал, дописал ещё тест, столкнулся с ошибкой и полтора часа просидел над нормальной реализацией. И теперь всё отлично.

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

А может быть юнит-тесты и не нужны? Можно использовать рефакторинг, ведение документации и ручное тестирование. Я, например, совершенно не представляю как тестировать генерируемые PDF-ки (можно открыть и грепнуть, но это смех, а не тестирование).

bdd

Уже 40 страниц думаю "а когда мы код будем писать?!", а текст всё дальше и дальше уводит от написания кода и упорно вдалбливает мысль о том, что первым делом постановка задачи, затем тесты, а затем всё остальное.
Забавно ещё то, что их тестовые примеры я от скуки (и по привычке) уже наговнокодил. А после посмотрел на предложенную в книге схему и почувствовал себя мудаком — код говно, нерасширяемый бесполезный ужас и вообще его писать не надо было.
Выводы? Читать книгу, код не трогать.

Парни, а эту штуковина не слишком много времени просит ей уделять?! Слишком много файлов на первый взгляд и слишком много опсаний — на второй. А тестирует тем же кодом, что и RSpec. Какой в ней понт?

Вот я читаю книгу по BDD, RSpec и Cucumber. С текущей скоростью закончу с ней через недели две-три. Что если мне писать тесты к новому проекту прям опо ходу изучения книги? И использовать сразу RSpec и Cucumber?

Покрываю, блин, тестами, jquery-плагин. Часть плагина сама по себе, часть плотно завязана на jquery. Что-то внутри подсказывает банально забить на тестирование jquery-части.

bdd

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


bddcasts.com выпустили 3ий скринкаст и стали платными собаки :( Нашел тут github.com что уже записано 10 выпусков, надеюсь солью потом на халяву :) а то 5$ за скринкаст жаба давит :) Но если собратся в 5ом то по 1уе за скринкаст — нормально