без TDD/BDD, писать кейзы для того чтобы писать кейзы - ад, поэтому кастую ад и РПЦ на твою голову

TDD вроде как и есть, только не все ещё привыкшые.
А вообще ты черезчур толстун - по делу инфу давай.

ноу проблем бро: http://i.imgur.com/yobvVqm.png

Сэнк ю бро :)
Хотя альтернативку я бы всё же рассмотрел.

Кукумбер рассмотри перед тем как развидеть:)

It was sarcazm baby.

wtf на пикче?!

Мэй би кто по теме всё таки видал что?
А то чет только мастера тонкого тролинга на борщах вскормленные внемли моему призыву :(

то же самое, что происходит при написании кейзов после написания кода: люди получают исцеление от недугов (по крайней мере, коллеги в это верят)

да блин, берешь любую смешную картинку с http://joyreactor.cc/ и подписываешь в гимпе нужную фразу

на борщах вскормленные

кто с троллингом к нам придет тот от комбинатора погибнет! (комбинатор — это что-то типа терминатора). Внемли Агде вездесущей!

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

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

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

хз, я как раз не кодер, а релиз-инженер/тестировщик.. когда приложение на 90% состоит из GUI и этот GUI кардинально меняется каждые полчаса, юнит-тестировать это невозможно. Особенно если вместо гуя флеш. Ну, можно юнит-тестировать жалкие оставшиеся куски бизнес-логики... но они всё равно тесно связаны с GUI и платформой (веб-сервисы, БД, application server, итп), так что тестирование жалких кусков всё равно напоминает какую-то отписку перед заказчиком, «qa имеет место быть». У меня довольно небольшой опыт, но во всех проектах где пытались ввести юнит-тесты с ними происходил один большой FAIL. Чуть больше успеха с интеграционными тестами... я написал несколько фреймворков для этого, но например программисты отказались писать BDD-тесты на человекочитаемом языке, т.к. «мы хотим писать на ЯП, а не на этом убожестве», но при этом аналитики не могут писать на ЯП и не могут донести мысль программистам, а сами программисты без аналитиков не могут и не хотят формулировать требования... Короче, тоже FAIL, но поменьше и другого рода. Так что баги чаще находят сами пользователи. Гораздо эффективней постоянно релизить, хотя бы каждую пару дней. Или нанять толпу щелкателей мышкой с зарплатой 500 баксов в месяц. Тесты оказались полезны только на вычислительных задачах (которых в вебе чуть более чем нисколько) и проверке грамматик DSL (которых также чуть более чем нисколько). Так что, как видишь, у меня остался осадочек от этих ваших юнит-тестов, отсюда и ответы такие, резкие как удар серпом по яйцам.

Это тоже.

Ну у мну ситуация обратная, я бэкэнд разработчик, зачастую совсем бэкэнд.

Т.е. пишем в основном логику, UI последний раз я трогал месяцев 7 назад и то на халтуре.

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

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

везет.)

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

Допустим, придумали игру, в которой есть риалтаймовое поле боя (персист в таблицу sql), и есть маг, воин и вор наследующиеся от базового класса «игрок» (тоже соотве таблички). Запилили, выкатили, юзеры радуются. В обед гейм-дизайнер говорит: чото фигня какая-то, у нас игра совсем не риалтайм, давайте сделаем бои походовыми. К шести вечера есть походовые бои, выкатываем, двачуем F5 на форуме. На форуме анонимус пишет: говно ваши походовые бои, вертайте назад риалтайм! Владельцы бизнеса: чорт посоны, не поправим в ближайшие 3 секунды — у нас упадут продажи!... В десять вечера есть новая реализация боя, который частично и риалтайм, и частично походовый - все злые разъезжаются на такси домой спать. Завтра в 10 SCRUM, главный геймдиз говорит: посоны, курнул я ночью гашика и понял: не нужно нам воина, мага и лучника. Оставим одного мага, а воина и лучника смешаем вместе.

т.е. как воплотители спеков еле-еле успеваем стучать по клавишам, чтобы тупо сочинять портянки SQL, которые будут делать миграции в БД. Смешение воина и лучника, например, может оказаться нетривиальной задачей, т.к. там замешаны такие страшные вещи как «игровой баланс» (который в это время пытается написать в экселе девочка-экономистка). Спрашивается, когда писать тесты? Зачем писать тесты? Максимум через пару недель (а скорее - к следующему утру) всё равно все тесты придется выкинуть в помойку и написать новые.

Смотри ссылку в комменте...

Спрашивается, когда писать тесты? Зачем писать тесты?

Сначала писать тесты, что бы задокументировать код, и знать что воин-лучник не шалит.

все тесты придется выкинуть в помойку и написать новые.

Имхо тесты вообще почти всегда пишутся на помойку(ну до стэйбла), по этому надо их писать так, что бы не жалко было выкинуть.

А вообще, это лишь означает что ваши манагеры черезчур жадны, и хотят побольше говнокода без, вдумчивой архитектуры(не исключено что это успешная бизнес стратегия в конкретном случае). Да и тесты, по крайней мере UT не должен писать QA, вообще ни в каком виде.

Ну и мой бэкэнд чуть более бэк обычно :)

Somehow related

Оставлю это здесь: http://theprofoundprogrammer.com/

Забавный ресурс, спасибо.

по крайней мере UT не должен писать QA, вообще ни в каком виде.

в команде из 5 человек нет «чистых» специальностей) Есть некие склонности. Я там был «программистом», но одновременно дизайнил гуй и админил. UI/UX спец не только дизайнил, но писал код (HTML/JS) и консультировал меня как правильно использовать его заготовки в рабочем GUI. Второй «программист» писал алгоритмы вместе с геймдизайнерами. QA кроме тестирования был почти полноправным геймдизайнером и писал разные тесты, в основном на java+selenium (когда задалбывало прокликивать мышкой). Итп

и знать что воин-лучник не шалит

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

без, вдумчивой архитектуры

agile же. требования формируют архитектуру :) Хвост виляет собакой :3 А т.к. требования меняются сто раз на дню, архитектура тоже меняется сто раз на дню. Когда то, что ты тестируешь, меняется быстрее, чем ты успеваешь написать на это тест, даже выделенный QA-developer не справится, не говоря уж о б обычных девелоперах, которым кроме тестов надо еще и логику к ним писать =)

Мне только показалось или оно нагенерированно?

У нас 3 человека в команде, но ситуация конечно другая. Ынтырпрайз и всё такое.

Не такой жесткий эджаил, но имхо по архитектуре лучше всё равно что то прикинуть прежде чем бросаться кодить. Даже если эджаил.

Мэй би вам стоит разбавить православный скрам канбаном?

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

Могу дать тебе другу ссылку. Впрочем, ты уже там был, наверняка :)