параща, отлаживай принтами. не блогодори…
>>348150
При том, что очень многие долбоёбы верят, что тесты избавляют от отладки.
>>348065
> На каких проектах применяли?
Стэк протоколов для узлов мобильных сетей
> Какой профит?
Ложная уверенность в корректности.
> Насколько сильное покрытие?
У нас было 90+%. Но покрытые - хуйня. Оно говорит, был вызван кусок кода или нет, но оно не сможет сказать, проверил ли кто-то результат выполнения куска кода. Всё что покрытие может сказать - при вызове покрытого кода с какими-то из хуя высосанными параметрами он не крэшится.
> мой якобы завершенный проект перед релизом был отдан профессиональному тестировщику на проверку. В итоге +1 месяц на багфиксы.
Ты сделал неправильные выводы из этой истории. Программы неизбежно взаимодействуют с реальным миром, когда ты пишешь программу то делаешь предположения относительно реального мира. Системы типов и тесты могут сказать, правильно ли ты написал код исходя из этих предположений. Но они не смогут сказать тебе, правильны твои предположения или нет. Поэтому нужно как можно раньше и чаще сталкивать программу с реальным миром, чтобы проверять свои предположения.
Если тебе всё-таки важны свойства именно кода (иногда такое бывает) и нужно проверить какие-то свойства программы, которые не способна проверить твоя система типов, используй генеративное тестирование - охуенная тема.
>>348169
Грамотные интеграционные и регресионные тесты практически избавляют.
>>348238
В общем, даже лень тебе что-то объяснять.
Таких, как ты — миллионы, серых и отвратительных, как плевки на асфальте. Приходящих сюда ежедневно с ведром грязной воды, которой мыли полы, вместо мыслей.
Вам все уже было сказано и не раз, поэтому и встречают вас пастами, апатией и предложениями уйти.
>>348241
Поехавший.
бамп
>>348216
Вот этот хорошо сказал. Еще добавлю, что чтобы не пиздели про скорость разработки TDD-шники - это реально замедляет. Анализирую по двум схожим проектам, где в одном 30 человек и нет TDD, в другом, более простом 100 человек и TDD. Так вот TDD реально проебывает кучу времени в никуда.
Для мобильных аппов TDD не нужно нахуй. Оно несет какую-то пользу только в тех проектах, где за фейл кода тебя могут выебать, нет, даже ВЫЕБАТЬ. Т.е. если пишется софт для банков и атомных реакторов с томографами. В 95% продуктов TDD только отжирает время и не дает никаких профитов.
Короче восхваляющие TDD фраерки гладко стелят, да жидко какают. Их примеры настолько притянуты за уши, что даже лень объяснять.
>>348307
>Оно несет какую-то пользу только в тех проектах, где за фейл кода тебя могут выебать, нет, даже ВЫЕБАТЬ. Т.е. если пишется софт для банков и атомных реакторов с томографами.
Вы путаете объективную необходимость покрытия кода тестами с ефективностью разработки функциональности, под которую уже написаны тесты.
>>348317
Если под эффективностью ты подразумеваешь скорость, то при TDD она ниже просто потому что нужно делать больше работы. И ты точно так же будешь подгонять результат работы что под тест, что под свою визуальную првоерку.
тред не читай @ ну ты понел
TDD создаёт возможность для проебывания времени сотрудниками - получается, что они могут написать свою условную норму кода за день, реализовав совсем немного функционала, ведь тест как правило пишется быстро хотя иной интеграционный тест и за день не напишешь, а уже тем более не заставишь работать
Мне помогает быстро накидать интерфейс класса, зная его обязанности. Правда я bdd, а не tdd использую. Пару раз отловил с помощью теста хитровыебанный баг в глубинах кода.
Проект уровня /gd.
В статике не нужно, лучше делать систему типов такой, чтобы проблем не было, в динамике - по-другому никак.
>>348367
Ой, вытекай клоун, со своим хачкелем и системой типов.
>>348368
Вообще-то я крестоблядь и матлабоопущенец, ну да ладно
>>348241
Это говорит петух, которому в пхп только принт и завезли.
О существовании дебагера и брэйк-поинтов он даже не подозревает.
Как же ты мразь меня заебала.
>>348382
Да это наверняка тухлая паста, из той же песни что и про господ с тростями и быдла с портвешком.
Объясните тупому, это только в Империи так, что один и тот же человек пишет и код, и тесты? Чому такая несправедливость. Я хочу писать только код, я же не говночистом устраиваюсь.
>>348382
нахера нужен дебагер ставишь принтефы/ассерты и смотришь в вывовод
скриптодрисню ведь не нужно конпелировать по десять часов
>>348427
Какие принты ты чо пидор еблан?
Любая макака выше юниора юзает xdebug для локального дебага, который интегрируется в любую нормальную IDE.
>>348431
> открыл файл - поставил принтеф - нашел ошибку - исправил - сохранил файл
> у еблана выше юниора только-только догрузилась любая нормальная IDT
>>348424
А ты вообще не английском что-нибудь читал по этой теме, пробовал хотя бы, кукарека?
>>348441
Читал. Пробовал. Ну пишешь всевозможные вызовы метода и "правильные ответы". Модифицируешь, проверяешь. Это же реально работа говночиста.
>>348424 компьютер проверит твою программу быстрее чем ты. если программа изменяет состояние, то просто запаришься возвращаться в предыдущее состояние. ну там записи в базе создать, вызвать какие-то процедуры. тестировщик не знает какие у тебя сущности, может не быть программистом.
но не отрицаю, если бы была точная спецификация, то кто-то мог бы написать тесты, а кто-то другой написать программу.
>>348439
Сука, как ты заебал меня.
А если тебе надо посмотреть с десяток полей в пяти объектах одновременно, сколько принтэфоф будешь ставить, а, обмудок?
Или в твоем мирке только стринги и интежеры с лаба1?
>>348492
for ($object_id = 1; $object_id <= 5; ++$object_id) {
print_r($objects[$object_id]);
}
сасай не закисай
>>348439
И не влом тебе по сто раз расставлять принтефы с ассертами, а потом выискивать их и удалят? Вообще долбоеб чтоли7
>>348526
#ifdef DEBUG
#define DEBUGO(...) printf("DEBUG OUTPUT: " VA_ARGS)
#else
#define DEBUGO(...)
#endif
>>348323
yes but tests, written before writing working code, may be also used after
>>348647
azazaz fucked your mother lolka
sent from my iPhone
>>348650
3====э --- 0-;
sprinkled mankin's mouth with urine
sent from my iPad
>>348651
BUTTERFLY of russian scum has not been noticed.
sent from my iPhone
>>348654
a shrill scream from the bucket
sent from my iPad
>>348639
If I had written as in Russian I would have put comma before the word "but".
>>348065
Использую TDD и заставляю своих программеров писать тесты - новички сопротивляются, те что по-старше - привыкли и начинают постигать Дзен.
Тесты позволяют реже запускать отладчик и сразу показывают где и что наебнулось из-за очередных "нововведений" в проект.
Поначалу написание тестов сжирает лютую кучу времени, потом - норм. Когда придет понимание - времени будешь затрачивать меньше, чем без них.
>>348169
>При том, что очень многие долбоёбы верят, что тесты избавляют от отладки.
да, избавляют практически. дебагером уже не надо постоянно елозить по говнокоду.
и дебажишь уже не весь проект, а один конкретный метод
юнит тесты должны создаватся автоматически
каждый югит должен иметь стандартизированную функцию (init) которая стирает текущее состаняние и приводит в начальное состояние
береш большой обьем реальных данных, проганяеш через програмный комплекс
пачки проходязих черех юниты данных разделенные на куски вызовами стандартной функции init образуют юниттесты
подпись-самый умный в Империи
А можно, например, так чтобы юниттест создавался автоматически. Ну типа пишешь метод, будем считать, что он отлажен и правильный, запускаешь генератор юниттеста, который ищет в коде все условные циклы, сам генерит набор входов и просто запускает метод, смотрит выход и запоминает его. Всё, дальше, если метод перелопачу, генератор проверит метод по данным наборам вход/выход.
if (crypt(input_string) == "080af230aa")
// do some stuffВряд ли, зато можно проверить покрытие теста, т.е. запустить тесты и посмотреть, все ли ветки кода они прогнали. (gcov)
>>348740
Либо у тебя под командованием отборные долбоебы которые ломают все до чего могут дотянуться, либо ты сам первопочинный долбоеб, который не понимает, что если придрочиться то, на что угодно уходит меньше времени. А на написание тестов уходит то же самое время котоыре тратится на отладку, если не больше. Нет, даже больше. Даже самый криворукий программист не может допустить ошибку в каждой тестируемой функции, а вот тестами покрывать придется каждую. И если у тебя правда работают такие ебланы как ты описываешь, то любой код напсианный в больших объемах повышает их уровень так, что кажется будто это тесты улучшают картину.
у меня такое ощущение, что вот такие >>348918 петухи, ничего сложней laba1 или сайта на WP в жизни не писали или про юнит-тесты говорят исключительно с дивана, оттуда же видней.
А вот если я хочу попетушиться и сделать сайт вроде 2ch.hk, мне нужны эти ваши юнит-тесты или нет?
>>348941
Для того, чтоб долбиться в пердак юнит-тесты не нужны.
>>348941
Вы какие-то ебанутые, честное слово, уже который месяц наблюдаю феерию долбоебизма в разрезе TDD.
Возьми, блядь, и попробуй. Вы же программисты, сука, вы каждый день что-то новое пробуете, а на TDD все смотрят, как на героин.
Даже упоротые рельсобляди уже осознали уёбищность TDD:
http://david.heinemeierhansson.com/2014/test-induced-design-damage.html
>>348927
Наконец-то я дождался козырного аргумента джава-петуха.
Я разочаровался в TDD уже в середине нулевых, но многим еще предстоит пройти этот путь, поверив псевдоаргументам адептов тестирования. Аргументы эти кстати не меняются годами, и в точности повторяют столь любимое быдлом "Да ты просто жизни не знаешь!" и "Вырастешь-поймешь!". TDD-шники - это такое агрессивное быдло ИТ, которое агрится на всех, кто не разделяет его точку зрения.
>>349034
> осознали уёбищность TDD
Орлы?
> Controllers are meant to be integration tested, not unit tested.
>>348216
> генеративное тестирование
Что это и как гуглить?
Какой смысл в этом TDD, если половину тестов придется переписывать при первом же рефакторинге?
>>349045
С нихуя сделать вывод да еще и настолько промахнуться - это просто сказка какая-то. Теперь я окончательно убедился в твоей упоротости.
>>349079
Нихуевый у тебя такой рефакторинг и изменением половины внешних интерфейсов. Если меняются публичные интерфейсы объектов - значит поменялись требования и их выполнение должно, очевидно, тестироваться по другому. Если же ты от нихуя неделанья взял и всё поменял - то извините, вам поможет только живительная эвтаназия.
>>349089
> половины внешних интерфейсов.
То есть TDD только на внешние интерфейсы распространяется?
>>349095
Ну как бы да, приватные методы, например, не тестируются, это детали реализации. Тест тестирует то, что доступно миру, а внутри ты хоть цирк коней пригласи.
>>349112
Хуй знает. По-моему утверждение, что вся архитектура сразу же пишется по спецификации и потом не рефакторится, это какие-то выдумки борщехлобов-теоретиков. Или сотрудников всяких НАСА.
>>349124
Понятно, что интерфейсы будут меняться и от этого никуда не деться, тем более в зачаточной стадии проекта, но тесты то тоже без фанатизма надо писать: если ты набрасываешь прототип модуля в отдельной ветке и сам еще ни в чем нихуя не уверен, то и тесты, очевидно, писать смысла нет.
Плюс, как ни странно, мне тесты перед написанием уже не прототипного кода помогают реже потом изменять публичные вещи, т.к. сама суть тестов подразумевает модульность и изолированность, что приводит к довольно сильной выверенности и четкости внешних интерфейсов.
Алсо, никакий спецификаций у меня обычно нет, просто обозначают конечную цель. Иногда согласовываем некоторые моменты взаимодействия с кодом других программистов.
блювать хоху(
>>349059
А ты каким сортом борща упарываешься?
Для наиболее распространённых вариантов:
Haskell - http://www.haskell.org/haskellwiki/Introduction_to_QuickCheck1
Erlang - http://www.erlang-factory.com/upload/presentations/19/quickchecktutorial_tartsjhughes.pdf
Clojure - https://github.com/clojure/test.check
>>348918
Лучше скажи нам, братюнь, как ты пишешь и как долго живут твои лабы? Приходилось ли тебе поднимать сырки софта, написанного год-два назад и начинать дорабатывать его? Менять предметную область?
Или ты как Чак Норрис - Ctrl+S и деплой?
>>348941
Для логики на сервере юнит-тесты не помешают. А вот как тестить вьюхи, я хз.
>>349079
Тесты покажут где и что сломал твой рефакторинг и надо ли было его проводить. Если все тестирование заключается в мышкой клац-клац и деплой, то да - от тестов толку ноль.
>>349172
У Чака Норриса автосохранение + хук на автосохранении деплоит в случае успешного билда.
>>349213
У него разве могут быть не успешные билды?? Анон, беду накликаешь.
И ни один не написал о том, что TDD вообще-то способен драйвить архитектуру, способствовать улучшенной инкапсуляции и прочее и прочее. В команде абизян это сильно способствует орднунгу. Тру стори, никролль.
>>349229
>A good illustration of this is the late Jim Weirich's demonstration of the hexagonal architecture in Rails. This presentation shows the fundamentals of the "decoupling from Rails" approach, without necessarily buying into it wholeheartedly as a general purpose approach (Jim was a pragmatic programmer, and I miss him dearly).
>While you're watching the presentation, listen to the justifications for the design. They're all about testing! It's about having faster tests, without touching the database, and it's about being able to test controller logic without dependent context.
>To achieve this, the simple controller is forbidden from talking directly to Active Record, now it has to go through the Repository. And the action itself is hollowed out to extract a Command object, which then has to call back into the controller through the Listener pattern.
>>349229
Про инкапсуляцию ты чой-то непонятное пукнул, поясни. Насчет орднунга - двачую. Тесты (у меня) почти всегда определяют рамки, согласованные с заказчиком - софтина должна работать так и никак иначе. Все остальные свистоперделки - в следующий релиз и следующее ТЗ.
Если после постановки ТЗ начинать с тестов, а потом загонять в их рамки логику, то и сроки не сорвешь и попаболи меньше. Особенно попаболи меньше, когда получаешь следующее ТЗ на доработку - можно сразу понять сколько времени это займет и что из существующего ломается.
>>349230
Да-да, все это уже 100 лет назад обсосали и если только ты не донор мозга, ты будешь иметь это ввиду.
>>349236
Ну что тебе непонятно? Что, ты не видел случаи, когда логика размазана на 2-3 сервиса\класса\ватэвер, шарят данные друг с другом и инициализируют по цепочке друг друга с конфигов, пути которых вколхожены прямо в класс и подобную хуету? Приходишь, криком поясняешь про юнит тест, и тут, вдруг, криворукого озаряет, что чтобы написать тест ему надо инициализировать кучу говна, подложить в какие-то левые места конфиги и тому подобное. И начинается рефакторинг просто чтобы нормально тест к этому говну написать.
>>349256
Криком надо пояснять, что сперва тест и интерфейсы сервисов, а только после Impl этих сервисов. Нах писать и натягивать тест на существующий говнокод с "вколхоженным" в него говном?
>>349266
Смысл-то не меняется - тесты в таком случае нужно только галочки и красивого coverage, но реально толку от них ноль.
>>349264
On a side note: как же меня бесит джавовские naming conventions типа HuiPizda, AbstractHuiPizda, HuiPizdaImpl. В дудке вот нормально придумали: IHuiPizda, AHuiPizda, HuiPizda. В исходника Clojure, например, используется дотнетовский подходи к именованию, хоть там и жаба.
>>349395
Это твои проблемы, остальным - норм. Хлебни лучше борща.
>>349395
Мне в дудке нэйминг больше нравится, но именование мемберов с заглавной буквы у меня вызывает кровавые слёзы.
>>349395
>В дудке вот нормально придумали
В джаве тоже дохуя либ, где используется такое же наименование.
>>349396
>Хлебни лучше борща.
Двачую этого адеквата. Глупо жаловаться на то, что ональные хозяева тебе на говно вишенку не так положили. Возьми нормальный борщеязык, и там будет и продуманый нейминг и всё прочее, и можно будет смело пиздеть в конфочках на разработчиков, если тебе что-то не понравится.
>>348776
А если код рефакторнуть? Придется все тесты перепиливать? Это ж охуеть как время разработки увеличит. Нахуя всё это?
Сейчас работаю над одним проектом на C++ без стандартной библиотеки. Написал свой небольшой фреймворк для юнит-тестов.
Пишу TDD - написал тесты, оно не компилируется. Написал прототипы методов/функций - компилируется, но не линкуется. Написал сами функции - тесты пройдены - ШИН. Можно порефакторить, запустить тесты и посмотреть, что по прежнему все работает.
>>349172
>Чак Норрис
>Ctrl+S
>не :w
>>349569
>ад одним проектом на C++ без стандартной библиотеки
UEFI?
>>349571
>:w
>2014
>не ZZ
нахуй пошёл
>>349587
Кто то ещё пользуется вимом для чего то кроме как правки одной строчки в конфиге?
>>349588
Пользуюсь для питонячьего, C, C++ кода. Планирую попробовать перекатиться на Emacs с evil'ом, когда будет время. или на neovim, если там нормальную многотредовость забацают
>>349589
давно пора
не пытайся эмулировать вим в имаксе, ничего не выйдет. учи сразу
>>349590
Учить сразу контролокомбинации и приобретать emacs pinky? Нет, спасибо. Уж лучше я все же попытаюсь осилить единственный нормальный текстовый редактор для имакса - evil.
Алсо по теме. Прошел через все стадии и в итоге пришел к смеси BDD, TDD и простого юнит тестирования. Зависимость есть, брат жив.
>>349597
лол, ctrl-болезнь
посмотрел, а у меня на клавиатуре только левый ctrl и есть
всё, имакс не светит мне ':-#
>>349137 http://cpputest.github.io вот мой, отлично подходит для няшной сишки с железками.
>>348065
Какой профит от этого говна? Что реально можно проверить юнит тестом, кроме как сравнить два int'a или две строки? Давайте реальные примеры, а не Я ПРАЧИТАЛ ЧТО TDD ЕТА МОДНА, УСТАНОВИЛ БИБЛИОТЕКУ И ТЕПЕРЬ ПРОВЕРЯЮ, ЧТО ДВА РАВНО ДВА ЕТА КРУТА Я У МАМЫ КРУТОЙ ДЕВЕЛОПЕР))
>>349707
Например:
it('must call validate method on input change', function(){
var spy = sinon.spy(formField, 'validate')
input.emit('change', {})
expect(spy.callCount).to.be(1)
spy.restore()
})
it('must update buffer on input execute', function(){
var buffer = form.get('buffer')
input.value = _.uniqueId()
input.emit(formField.get('executeEvent'), {})
expect(buffer.get(field.get('code'))).to.be(input.value)
})
>>349749
Или так:
it('#isValid() must return "all fields are valid"', function(){
fieldOne.valid = true
fieldTwo.valid = true
expect(form.isValid()).to.be.ok()
fieldOne.valid = false
expect(form.isValid()).to.not.be.ok()
})
it('must react on .valid property changes in fields', function(){
var spy = sinon.spy(form, 'validate')
fieldOne.set('valid', false)
expect(spy.callCount).to.be(1)
spy.restore()
})
>>349749>>349750
Какой охуительно полезный тест!
`it('#isValid() must return "all fields are valid"', function(){
fieldOne.valid = true
fieldTwo.valid = true
expect(form.isValid()).to.be.ok()
fieldOne.valid = false
expect(form.isValid()).to.not.be.ok()
})`
проверяет он что-то такое, да?
`
function isValid() {
return fieldOne.valid && fieldTwo.valid
}
`
>>349645
Не-не, тут речи шла именно о генеративном тестировании.
Там сначала декларативно описываются свойства функции, затем генераторы входных данных бомбят функцию инпутом и проверяют, выполняются ли свойства. Если свойства нарушаются, то фреймворк пытается сузить круг входных данных, при которых нарушаются свойства.
>>349759
Даже лень объяснять.
Ты просто видимо не писал сложные приложение и не знаешь как инкапсулированная логика внезапно может разрастись до космической сложности и такие очевидные, казалось бы, атомарные тесты, помогут тебе избежать фейла в дальнейшем.
Естественно, в форме не fieldOne и fieldTwo, а набор заведомо неизвестных полей и механизм, с помощью которого форма с ними работает внутри может постоянно изменяться.
>>349588
Vim рулит когда по SSH на сервере нужно что-то поправить. Программить локально с помощью Vim-а так и ниасилил - пробовал, но, блять, это как кактусы жрать и улыбаться при этом.
Адвентисты Седьмого Теста
Нет ну реально заебали. Вконец. Блядская секта, похуже хрестанутых. Что характерно, в секте состоит в основном всякая тупая копчёная индусня и прочие говноеды. При этом они считают всех не разделяющих их пидорастическую религию убогими, жалкими и недостойными называться программистами.
Я понимаю что объяснять что то фанатикам бесполезно, но всё же. А вдруг. Почему тесты говно? Тут есть несколько причин.
1. Чуть более чем всегда тестируют то что тестировать вхуй не впилось. Вплоть до:
def add(a, b)
a + b
end
2. Тесты эти практически всегда сложнее кода который они должны тестировать.
test 'add'
class NumberFactory
def self.produce_number(range)
rand(range)
end
end
assert(add(1, 1) == 2, 'я')
assert(add(1, -1) == 0, 'тупое')
assert(add(-1, -1) == -2, 'уёбище')
assert(add(10, 20) == 30, 'годное')
assert(add(10, -20) == -10, 'исключительно')
assert(add(-10, -20) == -30, 'на')
assert(add(1, 1) != 3, 'метан')
100.times do |x|
number_one = NumberFactory.produce_number(x + 1)
number_two = NumberFactory.produce_number(x + 1)
assert(add(number_one, number_two) == number_one + number_two, 'я мечтаю что бы меня трахнул чёрный властелин')
end
end
Я не шучу - 99% тестов выглядят примерно так и несут такую же пользу. Очень жаль, тупое говноедище (см. ссылку выше) закрыло все свои посты, там был реальный пример функции которая возвращал толи захардкоженую строку, толи к ней прицепляла параметр, чота такое. И адовые тесты на это с использованием каких то дичайших либ чота там делающих с байткодом и прочим пиздецом. Я не шучу.
3. Они дают ложное ощущение безопасности. Тесты прошли? Хуяк-хуяк и в продакшн. Ничего же плохого случиться не может. Кстати, вариант что тесты не учитывают все случаи или содержат ошибку не рассматривается вообще. Никогда. Когда с ебанашками пытаешься говорить на эту тему у них та куча поноса больного бешенством кенгуру, которая заменяет им мозг, начинает бурлить и никакого конструктивного диалога не получается.
4. Они отучают программистов думать. Нахуя думать если есть тесты? Тесты прошли - всё заебись. Не прошли - будем подгонять код под тесты. Этот пункт коррелирует с предыдущим. Нет смысла как то ещё проверять код при пройденных тестах (ну в смысле это пидорасики так считают).
5. Замечена закономерность. Чем больше тестов - тем меньше отладочных логов. А вот как разбираться с дейтсвительно хуёвым случаем когда раз в неделю в продакшне рандомно идёт по пизде целостность данных? Тесты тут ничем и никогда не помогут. Ну и да - тестами нереально оттестировать что нибудь сложное, когда 100500 процессов/потоков и данные хуярят гигабайтами в минуту.
Ну вот как то так. Возникает закономерный вопрос: чо, тесты не писать? Да нет - писать. Только правильные, функциональные, тесты. То есть пустить тестируемое приложение, накормить его реальными данными, дёрнуть типичные вокфловы и сравнить полученный результат с эталонным. Да - оно не покажет конкретного места где сломалось. Но серьёзно - оно вам надо? Вы не сможете найти в вашем коммите (ну или в более сложном случае - в паре-тройке коммитов, при мерже) место в котором что то сломалось? Ну тогда идите работать в зоопарк, младшим помощником старшего уборщика кала африканской антилопы Вени, на большее у вас не хватает способностей.
Ситуация осложняется тем что эти тупопёздые пожиратели страусиного кала в подавляющем большинстве случаев страдают сопутствующими помешательствами - паттернодрочерство, хымыылефилия, энтерпрайз головного мозга и прочими.
Ебитесь раком (tm).
PS. Я реально в одном проекте видел тесты к тестам. Натурально. Моя жизнь уже никогда не будет прежней.
http://theiced.livejournal.com/254704.html
>>349903
Ну и нахуя он с этими недоумками в одном проекте работает, раз такой Д'Артаньян? Жрёт говно и жалуется, охуеть. Любой подход можно довести до маразма, тоже мне, Америку открыл.
>>349890
что именно неудобно?
>>349903
>Я не шучу - 99% тестов выглядят примерно так и несут такую же пользу. Очень жаль, тупое говноедище (см. ссылку выше) закрыло все свои посты, там был реальный пример функции которая возвращал толи захардкоженую строку, толи к ней прицепляла параметр, чота такое. И адовые тесты на это с использованием каких то дичайших либ чота там делающих с байткодом и прочим пиздецом. Я не шучу.
Наверное это очень важная функция, которая возвращает какой-то id, использующийся в проекте, тогда имеет смысл делать отдельный тест на генерацию этого id, чтобы было видно, если функция его генерации сломалась (если кто-то решил переписать её). Вполне нормальная ситуация.
>3. Они дают ложное ощущение безопасности. Тесты прошли? Хуяк-хуяк и в продакшн. Ничего же плохого случиться не может. Кстати, вариант что тесты не учитывают все случаи или содержат ошибку не рассматривается вообще. Никогда. Когда с ебанашками пытаешься говорить на эту тему у них та куча поноса больного бешенством кенгуру, которая заменяет им мозг, начинает бурлить и никакого конструктивного диалога не получается.
Ну это просто они - ебанашки, тесты ведь не виноваты в этом?
>4. Они отучают программистов думать. Нахуя думать если есть тесты? Тесты прошли - всё заебись. Не прошли - будем подгонять код под тесты. Этот пункт коррелирует с предыдущим. Нет смысла как то ещё проверять код при пройденных тестах (ну в смысле это пидорасики так считают).
Вообще-то они должны думать о слабых местах и когда пишут сам код, и когда пишут тесты. Тесты как раз и нужны, чтобы описать все слабые места, чтоб потом можно было сделать те же проверки для подправленного кода - но, конечно не факт, что этих проверок достаточно для проверки подправленного кода, но можно хотя бы, читая тест, посмотреть, что именно проверяли раньше и подумать что можно ещё проверить.
>5. Замечена закономерность. Чем больше тестов - тем меньше отладочных логов. А вот как разбираться с дейтсвительно хуёвым случаем когда раз в неделю в продакшне рандомно идёт по пизде целостность данных? Тесты тут ничем и никогда не помогут. Ну и да - тестами нереально оттестировать что нибудь сложное, когда 100500 процессов/потоков и данные хуярят гигабайтами в минуту.
Где такая закономерность? У ебанашек? :3
>Ну вот как то так. Возникает закономерный вопрос: чо, тесты не писать? Да нет - писать. Только правильные, функциональные, тесты. То есть пустить тестируемое приложение, накормить его реальными данными, дёрнуть типичные вокфловы и сравнить полученный результат с эталонным.
Не всегда удобно писать функциональные тесты, но когда их можно написать достаточно просто - конечно стоит. Но от всех тестов есть своя польза, и от юнит-тестов, и от интеграционных тестов, и от функциональных тестов. Правда надо оценивать, можно ли их написать достаточно эффективно, т.к. пишу код 5 минут, а потом тест целый день - это хуета и не нужно. Нормальный workflow - пишу тестик, что мне надо от функции, пишу заглушку, которая его не проходит, правлю её код до функции, которая тест проходит, возможно добавляю test case-ы, которые были не очевидны до написания функции. Но такое удобно для сетевого кода, например, или для работы с данными, а для программирования UI - не годится.
>PS. Я реально в одном проекте видел тесты к тестам. Натурально. Моя жизнь уже никогда не будет прежней.
А в чём, собственно, проблема? Надо же периодически проверять, что тесты не сломались - если это можно делать автоматически - то здорово! Остаётся проверить вручную только тест к тестам :3
>проверить вручную только тест к тестам
Никогда нельзя останавливаться,
но прозреваю рекурсивные тесты.
>>349942>>349934
И внезапно идея, которая витала в воздухе.
В банках часто используют метод двух персон.
Еще там стараются делать тайный метод двух персон,
так что каждая сторона не знает, где другая.
Я это к чему.
У нас есть некое нечто, имеющее состояние (например, записи в БД). У нас есть тест, который переводит некую вещь из состояние 1 в противоположное состояние 2. И у нас есть тест, делающий обратное преопразование. Делаем третий тест, который херачит вот такое 1-2-1-2-1 и 2-1-2-1-2, сверяя одинаковость происходящего, используя первые два теста. Идеально, если все три херотни лежат в разных модулях. И разрабатываются в разных компаниях.. извините, я не могу сдержать смех и печатать дальше
>>349554
>А если код рефакторнуть? Придется все тесты перепиливать? Это ж охуеть как время разработки увеличит. Нахуя всё это?
код рефакторится при помощи встроенных в ide средств.
когда используешь TDD изначально, получается хорошая арихтектура и код, который требует уже меньше рефакторинга
> когда используешь TDD изначально, получается хорошая арихтектура и код
Всё совсем наоборот.
То что ты отделяешь интерфейс от реализации и формализуешь требования к коду вообще не гарантирует что код и архитектура не будут говном. А из-за того, что такие долбоёбы как ты, думают, что при использовании ТДД ПО само становится качественным, всё только хуже получается.
В тдд ты сначала пишешь тесты и делаешь так, чтобы они выполнялись, похуй как, потом если есть время, это говно рефакторится. Это такая философия, что иногда действительно можно забить на красоту в угоду ЛИЖБЫРАБОТАЛО. Это называется аджайл.
А если ты хочешь сразу всё делать качественно, ты блядь не поверишь, надо сидеть и головой думать, как сделать качественно, а не тесты хуярить.
>>350101
Изо дня в день проигрываю в этом треде. Диванные эксперты объяснят вам, что писать тесты - это вам не головой думать, это пальцы сами пишут. Так же, в порыве капитанства они уведомят вас о том, что тесты по умолчанию не гарантируют высокого качества кода, а потом упомянут "так, чтобы они выполнялись, похуй как", будто ты бы это что-то новое, а не принцип, старый как мир: "сделай, чтобы работало -> сделай красиво -> сделай быстро" и даже в сторону этого тезиса они начнут бросаться какашками, пребывая в полном неведении о том (а как узнать то, если не тестируешь, а вещаешь с дивана), что человек, привыкший выделять правильные абстракции (а без этого не научиться писать хорошие тесты) напишет "чтобы работало" намного качественней, чем макака, привыкшая писать код, как бог на душу положит, но "думая головой".
> что человек, привыкший выделять правильные абстракции (а без этого не научиться писать хорошие тесты) напишет "чтобы работало" намного качественней, чем макака, привыкшая писать код, как бог на душу положит, но "думая головой"
Ты какой-то ебанутый, правда же.
Моя логика:
1) Если ты будешь писать тесты, ты научишься писать тесты и протестируешь своё приложение, избавишься от всяких глупых и случайных ошибок.
2) Если ты будешь писать код думая головой, ты научишься писать более качественный код.
Твоя логика:
Если ты будешь писать тесты, ты будешь выделять правильные абстракции, отвыкнешь писать код "как бог на душу положит", получишь хорошую архитектуру и код.
Тут блядь всё просто, или, по-твоему, качество кода является прямым следствием написания тестов или нет.
Если нет, то какая нахуй разница, писал ты тесты или нет. У плохого программиста тесты будут такими же некачественными как и его код.
>>350125
Давай просто уточним один момент перед продолжением разговора (а то такое ощущение, что ты выхватываешь процентов десять информации из моих постов) - ты юнит-тесты пробовал писать на настоящих проектах недельку другую хотя бы?
>>350137
Я понимаю, что тебе по сути ответить нечего, но если тебе так интересно, то я уже не первый год во всех проектах пишу тесты. И я не собираюсь продолжать с тобой разговор.
Стоит ли при использовании TDD рефакторить сами тесты? Как православно это делать?
>>350310
Нет. Блядь, с какого хуя у тебя внешнее поведение меняется, если ты рефакторишь?
>>350144
Не понял, а зачем ты их пишешь, если тебе не нравится?
Приведи, пожалуйста, пример типичного теста, который вы пишете в конторе. А лучше пару тройку.
>>350405
Какое нахуй внешнее поведение, ты о чем вообще?
>>349934
>что именно неудобно?
Привык пользоваться IDE-шными плюшками вроде "Introduce variable", "Extract Method/Field", "Inline", "Refactor this", psvm, sout,...
Наверное можно обмазаться всем этим в vim-е, но зачем?
ООП,
Паттерны,
Юниттесты,
ТДД,
Тесты к тестам,
Тесты к тестам тестов,
Тесты к тестам тестов тестов
...
какое ещё говно они придумают, чтобы программист окончательно превратился в фасовщика на конвейере? Уже пиздец, защита от дурака дураков, блядь, а не кодинг. Дальше, мне кажется, или автоматизация сродни индустриальной революции в Европе или ад и погибель.
Хочу знать мнение анона по теме TDD. На каких проектах применяли? Какой профит? Насколько сильное покрытие? Что покрывать в первую очередь? Доставляет ли обмазываться юнит-тестами?
лично я занимаюсь мобильной разработкой по iOS и давно посматриваю в сторону TDD, особенно сильно после того как мой якобы завершенный проект перед релизом был отдан профессиональному тестировщику на проверку. В итоге +1 месяц на багфиксы.