погоди

ты про РАМКИ тестируемого кода писал

если какая-то хуйня творится в другом используемом классе

то это уже не моя забота

а я всё ещё пишу про рамки тестируемого кода

другими словами

def abc(a)

if a

Foo.new(a)

else

raise "crap"

end

describe '#abc'

context 'a is valid' do

context 'a is nil'

ну я и говорю, проверяются варианты, которые ты видишь

что там творится в Foo.new(a) - проверять чисто факультативно

если что-то не увидел — оно не проверяется

жизнь такая

твои предложения?

нет предложений

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

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

cache-strategy смотри

ну и ниже от этого сообщения

спасибо

нет предложений

поймал баг - написал тест - поправил баг

это не к спору, это к предложению

Bug Driven Development :)

поймал баг - написал тест - поправил баг

вот мне эта стратегия больше нравится

больше чем что?

чем test first

*телепат мод*

это стратегия правки багов, она априори не может быть test-first *КО мод*

за поймал баг – написал тест можно нехило так выгребсти

предметные области разные же бывают. не всегда баг – статья новостного сайта, которая криво отобразилась

предметные области разные же бывают. не всегда баг – статья новостного сайта, которая криво отобразилась

особенно если идет работа с финансами

угу

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

Старые статьи http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html

http://david.heinemeierhansson.com/2014/test-induced-design-damage.html

это стратегия правки багов, она априори не может быть test-first *КО мод*

ну вот. Он за правку багов. А не за test first

особенно если идет работа с финансами

я читал, как проверяют работу с финасами

на продакшене проверяют )

на продакшене тоже, конечно, проверяют)

потому что вот это

Coverage report generated for RSpec to /home/teamcity/TeamCity/buildAgent/work/494ec52315d4bd9/coverage. 7915 / 8121 LOC (97.46%) covered.

ничего не гарантирует на самом деле

просто снижает вероятность проблемы

но все кейсы протестировать невозможно, как писалось выше

даже если есть специальные аналитики, куа-инженеры и прочие кейсописатели

#работа Мы разработали умного бота-рекрутера @xorappbot и хотели попросить сообщество попробовать потестить его. XOR позволяет прямо из нашего вашего мессенджера искать работу или специалистов в IT-сфере, как в России, так и по всему миру. База данных вакансий и позиций пополняется за счет пользователей сообществ, где подключен XOR и уже сейчас его подключили несколько технических и стартап-сообществ, а также за счет стартапов, подключенных к системе. Основные операции в XOR: *JobSearch* - для тех, кто ищет работу. Вы можете заполнить пожелания к работе, и когда подходящие предложения появятся - бот пришлет их вам. *Hire* - для поиска IT-специалистов себе в команду. *Support* - для тех кто запутался или столкнулся с каикми-то сложностями, тут можно задавать любые вопросы по работе XOR. XOR.ai сейчас работает на нескольких мессенджерах (slack, telegram), позже на этой неделе будет facebook messenger и skype. Подробнее можно посмотреть тут http://xor.ai , также есть FAQ http://xor.ai/faq Приложение в паблик бете. Сейчас вакансии можно запостить абсолютно бесплатно. @xorappbot ссылка на бота

ничего не гарантирует на самом деле

ничего не гарантирует - ну прекрасно - шикарный гуманитарный подход, слава логике! гарантирует например что при удалении/переименовани/рефакторинге класса тесты упадут … еще 100 примеров

просто фабрики написанные без тестов уже гарантируют что сферический объект в вакууме может быть создан

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

значит хуйовые тесты

нельзя дать 100% гарантию ничего не гарантирует почувствуй разницу

есть ли научная полученная оценка, которая показывает, что кол-во тестов влияет на кол-во багов?

#работа Мы разработали умного бота-рекрутера @xorappbot и хотели попросить сообщество попробовать потестить его. XOR позволяет прямо из нашего вашего мессенджера искать работу или специалистов в IT-сфере, как в России, так и по всему миру. База данных вакансий и позиций пополняется за счет пользователей сообществ, где подключен XOR и уже сейчас его подключили несколько технических и стартап-сообществ, а также за счет стартапов, подключенных к системе. Основные операции в XOR: *JobSearch* - для тех, кто ищет работу. Вы можете заполнить пожелания к работе, и когда подходящие предложения появятся - бот пришлет их вам. *Hire* - для поиска IT-специалистов себе в команду. *Support* - для тех кто запутался или столкнулся с каикми-то сложностями, тут можно задавать любые вопросы по работе XOR. XOR.ai сейчас работает на нескольких мессенджерах (slack, telegram), позже на этой неделе будет facebook messenger и skype. Подробнее можно посмотреть тут http://xor.ai , также есть FAQ http://xor.ai/faq Приложение в паблик бете. Сейчас вакансии можно запостить абсолютно бесплатно. @xorappbot ссылка на бота

и кто-то читает эту простыню?

есть ли научная полученная оценка, которая показывает, что кол-во тестов влияет на кол-во багов?

да, называется медицина

с медицной я вкурсе

да, называется медицина

вот это поворот

вопрос про код

теория научного эксперимента одинаково применима как к медицине/физике/информатике так и к программировнияю

отлично, есть такие данные про тесты и баги?

да, в медицине, багов было больше пока не сделали double-blind

ERROR: S client not available

:)

блять

%)

это общая теория :)

ну блин, влияет, если тесты есть – багов реально меньше )

и скорость кодописания выше

так вот есть есть тестировние таким способом двух вариантов ?

потому что в коде меньше багов

очевидно, что в тесте могут быть баги тоже

каких двух вариантов? тут для репрезентативной выборки нужна эволюция тысяч проектов

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

с багтреккером

а если тестов нет

это можно сделать и посфактум

то все обычно делается жопой на коленке

батхерттреккер

и не будет такой статистики

будет

откуда?

наса и ibm делали такие исследоания

комманда не пишет тесты -> в ней херово организован процесс производства

-> нихера она не ведет статистику

также считали сколько багов на lines

а мы говорим, что данные нужны за длительный период

:) люди шпилят проекты, потом пытаются 10к строк протестировать, а потом плявляются статьи что тесты боль/не нужно/тдд мертв но статистики не появляется

соотвевтенно наса как и ЕКА разработали свои гайды для программиирвоания

на основе этих исследований

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

соотвевтенно наса как и ЕКА разработали свои гайды для программиирвоания

есть ссылки на гайды?

нельзя дать 100% гарантию ничего не гарантирует почувствуй разницу

я понимаю) но немного утрирования о наболевшем иногда можно себе позволить

ну значит я повелся на троллинг

и кто-то читает эту простыню?

попыталась сократить... Спасибо за фидбек :)