Сохранен 141
https://2ch.hk/pr/res/348065.html
Из-за проблем с продлением домена ARHIVACH.NET, с 13 октября он может перестать функционировать. В связи с этим Архивач временно переходит на использование прежнего домена ARHIVACH.NG.
Напоминаем, что сайт всегда доступен через Tor по адресу arhivachovtj2jrp.onion. Установите Tor Browser для беспрепятственного доступа!

TDD

 Аноним Вск 27 Апр 2014 02:42:47  #1 №348065 
1398552167189.png

Хочу знать мнение анона по теме TDD. На каких проектах применяли? Какой профит? Насколько сильное покрытие? Что покрывать в первую очередь? Доставляет ли обмазываться юнит-тестами?

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

Loading...
sageАноним Вск 27 Апр 2014 13:48:43  #2 №348143 

параща, отлаживай принтами. не блогодори…

Аноним Вск 27 Апр 2014 14:16:53  #3 №348150 

>>348143
при чем тут отладка, уважаемый дебил?

Аноним Вск 27 Апр 2014 15:41:43  #4 №348169 

>>348150
При том, что очень многие долбоёбы верят, что тесты избавляют от отладки.

Аноним Вск 27 Апр 2014 16:32:02  #5 №348186 

>>348169
breaking news

Аноним Вск 27 Апр 2014 17:46:19  #6 №348216 

>>348065
> На каких проектах применяли?
Стэк протоколов для узлов мобильных сетей
> Какой профит?
Ложная уверенность в корректности.
> Насколько сильное покрытие?
У нас было 90+%. Но покрытые - хуйня. Оно говорит, был вызван кусок кода или нет, но оно не сможет сказать, проверил ли кто-то результат выполнения куска кода. Всё что покрытие может сказать - при вызове покрытого кода с какими-то из хуя высосанными параметрами он не крэшится.

> мой якобы завершенный проект перед релизом был отдан профессиональному тестировщику на проверку. В итоге +1 месяц на багфиксы.
Ты сделал неправильные выводы из этой истории. Программы неизбежно взаимодействуют с реальным миром, когда ты пишешь программу то делаешь предположения относительно реального мира. Системы типов и тесты могут сказать, правильно ли ты написал код исходя из этих предположений. Но они не смогут сказать тебе, правильны твои предположения или нет. Поэтому нужно как можно раньше и чаще сталкивать программу с реальным миром, чтобы проверять свои предположения.

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

Аноним Вск 27 Апр 2014 19:05:54  #7 №348238 

>>348169
Грамотные интеграционные и регресионные тесты практически избавляют.

Аноним Вск 27 Апр 2014 19:20:53  #8 №348241 

>>348238
В общем, даже лень тебе что-то объяснять.
Таких, как ты — миллионы, серых и отвратительных, как плевки на асфальте. Приходящих сюда ежедневно с ведром грязной воды, которой мыли полы, вместо мыслей.
Вам все уже было сказано и не раз, поэтому и встречают вас пастами, апатией и предложениями уйти.

sageАноним Вск 27 Апр 2014 19:34:44  #9 №348242 
1398612884145.gif

>>348241
Поехавший.

Аноним Вск 27 Апр 2014 19:42:20  #10 №348243 

>>348242
> серый плевок на асфальте зашевелился

Аноним Вск 27 Апр 2014 22:03:11  #11 №348287 

бамп

Аноним Вск 27 Апр 2014 22:42:31  #12 №348307 

>>348216

Вот этот хорошо сказал. Еще добавлю, что чтобы не пиздели про скорость разработки TDD-шники - это реально замедляет. Анализирую по двум схожим проектам, где в одном 30 человек и нет TDD, в другом, более простом 100 человек и TDD. Так вот TDD реально проебывает кучу времени в никуда.

Для мобильных аппов TDD не нужно нахуй. Оно несет какую-то пользу только в тех проектах, где за фейл кода тебя могут выебать, нет, даже ВЫЕБАТЬ. Т.е. если пишется софт для банков и атомных реакторов с томографами. В 95% продуктов TDD только отжирает время и не дает никаких профитов.

Короче восхваляющие TDD фраерки гладко стелят, да жидко какают. Их примеры настолько притянуты за уши, что даже лень объяснять.

Аноним Вск 27 Апр 2014 23:13:07  #13 №348317 

>>348307
>Оно несет какую-то пользу только в тех проектах, где за фейл кода тебя могут выебать, нет, даже ВЫЕБАТЬ. Т.е. если пишется софт для банков и атомных реакторов с томографами.

Вы путаете объективную необходимость покрытия кода тестами с ефективностью разработки функциональности, под которую уже написаны тесты.

Аноним Вск 27 Апр 2014 23:45:49  #14 №348323 

>>348317

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

Аноним Пнд 28 Апр 2014 00:48:10  #15 №348338 

тред не читай @ ну ты понел
TDD создаёт возможность для проебывания времени сотрудниками - получается, что они могут написать свою условную норму кода за день, реализовав совсем немного функционала, ведь тест как правило пишется быстро хотя иной интеграционный тест и за день не напишешь, а уже тем более не заставишь работать

Аноним Пнд 28 Апр 2014 03:24:36  #16 №348366 

Мне помогает быстро накидать интерфейс класса, зная его обязанности. Правда я bdd, а не tdd использую. Пару раз отловил с помощью теста хитровыебанный баг в глубинах кода.
Проект уровня /gd.

Аноним Пнд 28 Апр 2014 03:28:15  #17 №348367 

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

Аноним Пнд 28 Апр 2014 04:01:46  #18 №348368 

>>348367
Ой, вытекай клоун, со своим хачкелем и системой типов.

Аноним Пнд 28 Апр 2014 04:38:10  #19 №348370 

>>348368
Вообще-то я крестоблядь и матлабоопущенец, ну да ладно

Аноним Пнд 28 Апр 2014 08:04:40  #20 №348382 

>>348241
Это говорит петух, которому в пхп только принт и завезли.
О существовании дебагера и брэйк-поинтов он даже не подозревает.
Как же ты мразь меня заебала.

Аноним Пнд 28 Апр 2014 09:37:53  #21 №348400 

>>348382
Да это наверняка тухлая паста, из той же песни что и про господ с тростями и быдла с портвешком.

Аноним Пнд 28 Апр 2014 12:30:44  #22 №348424 

Объясните тупому, это только в Империи так, что один и тот же человек пишет и код, и тесты? Чому такая несправедливость. Я хочу писать только код, я же не говночистом устраиваюсь.

Аноним Пнд 28 Апр 2014 12:34:34  #23 №348427 

>>348382
нахера нужен дебагер ставишь принтефы/ассерты и смотришь в вывовод
скриптодрисню ведь не нужно конпелировать по десять часов

sageАноним Пнд 28 Апр 2014 12:38:45  #24 №348431 

>>348427
Какие принты ты чо пидор еблан?
Любая макака выше юниора юзает xdebug для локального дебага, который интегрируется в любую нормальную IDE.

Аноним Пнд 28 Апр 2014 13:04:13  #25 №348439 

>>348431
> открыл файл - поставил принтеф - нашел ошибку - исправил - сохранил файл
> у еблана выше юниора только-только догрузилась любая нормальная IDT

Аноним Пнд 28 Апр 2014 13:07:36  #26 №348441 

>>348424
А ты вообще не английском что-нибудь читал по этой теме, пробовал хотя бы, кукарека?

Аноним Пнд 28 Апр 2014 13:14:47  #27 №348444 

>>348441
Читал. Пробовал. Ну пишешь всевозможные вызовы метода и "правильные ответы". Модифицируешь, проверяешь. Это же реально работа говночиста.

Аноним Пнд 28 Апр 2014 13:51:36  #28 №348456 

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

Аноним Пнд 28 Апр 2014 15:54:06  #29 №348492 

>>348439
Сука, как ты заебал меня.
А если тебе надо посмотреть с десяток полей в пяти объектах одновременно, сколько принтэфоф будешь ставить, а, обмудок?
Или в твоем мирке только стринги и интежеры с лаба1?

Аноним Пнд 28 Апр 2014 16:38:43  #30 №348503 

>>348492
for ($object_id = 1; $object_id <= 5; ++$object_id) {
print_r($objects[$object_id]);
}
сасай не закисай

Аноним Пнд 28 Апр 2014 16:40:51  #31 №348505 

>>348503
Ох лол.

sageАноним Пнд 28 Апр 2014 16:42:12  #32 №348507 

>>348503
затралил его ващи бротишь))))))

Аноним Пнд 28 Апр 2014 17:13:22  #33 №348526 

>>348439
И не влом тебе по сто раз расставлять принтефы с ассертами, а потом выискивать их и удалят? Вообще долбоеб чтоли7

Аноним Пнд 28 Апр 2014 17:50:09  #34 №348548 

>>348526
#ifdef DEBUG
#define DEBUGO(...) printf("DEBUG OUTPUT: " VA_ARGS)
#else
#define DEBUGO(...)
#endif

Аноним Пнд 28 Апр 2014 21:11:13  #35 №348627 

>>348323
yes but tests, written before writing working code, may be also used after

Аноним Пнд 28 Апр 2014 21:32:36  #36 №348639 

>>348627
>пунктуация как в русском

Аноним Пнд 28 Апр 2014 21:38:31  #37 №348641 

>>348639
Native speaker
sent from my iPhone

sageАноним Пнд 28 Апр 2014 21:40:13  #38 №348642 

>>348641
sak dik kant))
sent from my iPad

Аноним Пнд 28 Апр 2014 21:42:40  #39 №348645 

>>348642
self
sent from my iPhone

sageАноним Пнд 28 Апр 2014 21:44:39  #40 №348647 

>>348645
drain counted
sent from my iPad

Аноним Пнд 28 Апр 2014 21:46:32  #41 №348650 

>>348647
azazaz fucked your mother lolka
sent from my iPhone

sageАноним Пнд 28 Апр 2014 21:49:27  #42 №348651 

>>348650
3====э --- 0-;
sprinkled mankin's mouth with urine
sent from my iPad

Аноним Пнд 28 Апр 2014 21:54:22  #43 №348654 

>>348651
BUTTERFLY of russian scum has not been noticed.
sent from my iPhone

sageАноним Пнд 28 Апр 2014 21:55:44  #44 №348655 

>>348654
a shrill scream from the bucket
sent from my iPad

Аноним Пнд 28 Апр 2014 22:55:41  #45 №348701 

>>348639
If I had written as in Russian I would have put comma before the word "but".

Аноним Втр 29 Апр 2014 00:01:09  #46 №348740 

>>348065
Использую TDD и заставляю своих программеров писать тесты - новички сопротивляются, те что по-старше - привыкли и начинают постигать Дзен.

Тесты позволяют реже запускать отладчик и сразу показывают где и что наебнулось из-за очередных "нововведений" в проект.

Поначалу написание тестов сжирает лютую кучу времени, потом - норм. Когда придет понимание - времени будешь затрачивать меньше, чем без них.

Аноним Втр 29 Апр 2014 01:57:37  #47 №348765 

>>348701
You should have done that in English too

Аноним Втр 29 Апр 2014 04:47:12  #48 №348776 

>>348169
>При том, что очень многие долбоёбы верят, что тесты избавляют от отладки.

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

и дебажишь уже не весь проект, а один конкретный метод

Аноним Втр 29 Апр 2014 04:48:43  #49 №348777 

>>348776 подпись отклеилась

TDD - практик

Аноним Втр 29 Апр 2014 04:55:53  #50 №348778 

юнит тесты должны создаватся автоматически
каждый югит должен иметь стандартизированную функцию (init) которая стирает текущее состаняние и приводит в начальное состояние
береш большой обьем реальных данных, проганяеш через програмный комплекс
пачки проходязих черех юниты данных разделенные на куски вызовами стандартной функции init образуют юниттесты
подпись-самый умный в Империи

Аноним Втр 29 Апр 2014 13:34:51  #51 №348896 

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

sageАноним Втр 29 Апр 2014 14:36:29  #52 №348912 

>>348655
Lol
sent from my MK-61

sageАноним Втр 29 Апр 2014 14:38:52  #53 №348913 

>>348896

if (crypt(input_string) == "080af230aa")
// do some stuff

Вряд ли, зато можно проверить покрытие теста, т.е. запустить тесты и посмотреть, все ли ветки кода они прогнали. (gcov)
Аноним Втр 29 Апр 2014 14:42:24  #54 №348918 

>>348740

Либо у тебя под командованием отборные долбоебы которые ломают все до чего могут дотянуться, либо ты сам первопочинный долбоеб, который не понимает, что если придрочиться то, на что угодно уходит меньше времени. А на написание тестов уходит то же самое время котоыре тратится на отладку, если не больше. Нет, даже больше. Даже самый криворукий программист не может допустить ошибку в каждой тестируемой функции, а вот тестами покрывать придется каждую. И если у тебя правда работают такие ебланы как ты описываешь, то любой код напсианный в больших объемах повышает их уровень так, что кажется будто это тесты улучшают картину.

Аноним Втр 29 Апр 2014 15:00:08  #55 №348927 

у меня такое ощущение, что вот такие >>348918 петухи, ничего сложней laba1 или сайта на WP в жизни не писали или про юнит-тесты говорят исключительно с дивана, оттуда же видней.

Аноним Втр 29 Апр 2014 15:28:11  #56 №348935 

>>348927
Так и есть.

Аноним Втр 29 Апр 2014 15:36:30  #57 №348941 

А вот если я хочу попетушиться и сделать сайт вроде 2ch.hk, мне нужны эти ваши юнит-тесты или нет?

Аноним Втр 29 Апр 2014 15:44:52  #58 №348947 

>>348941
Для того, чтоб долбиться в пердак юнит-тесты не нужны.

Аноним Втр 29 Апр 2014 16:09:06  #59 №348962 

>>348941
Вы какие-то ебанутые, честное слово, уже который месяц наблюдаю феерию долбоебизма в разрезе TDD.
Возьми, блядь, и попробуй. Вы же программисты, сука, вы каждый день что-то новое пробуете, а на TDD все смотрят, как на героин.

Аноним Втр 29 Апр 2014 16:56:06  #60 №348980 

>>348962
Я стесняюсь.

Аноним Втр 29 Апр 2014 18:06:24  #61 №349034 

Даже упоротые рельсобляди уже осознали уёбищность TDD:
http://david.heinemeierhansson.com/2014/test-induced-design-damage.html

Аноним Втр 29 Апр 2014 18:15:27  #62 №349045 

>>348927

Наконец-то я дождался козырного аргумента джава-петуха.

Аноним Втр 29 Апр 2014 18:22:09  #63 №349052 

Я разочаровался в TDD уже в середине нулевых, но многим еще предстоит пройти этот путь, поверив псевдоаргументам адептов тестирования. Аргументы эти кстати не меняются годами, и в точности повторяют столь любимое быдлом "Да ты просто жизни не знаешь!" и "Вырастешь-поймешь!". TDD-шники - это такое агрессивное быдло ИТ, которое агрится на всех, кто не разделяет его точку зрения.

Аноним Втр 29 Апр 2014 18:23:30  #64 №349053 

>>349034
> осознали уёбищность TDD
Орлы?
> Controllers are meant to be integration tested, not unit tested.

Аноним Втр 29 Апр 2014 18:42:44  #65 №349059 

>>348216
> генеративное тестирование
Что это и как гуглить?

Аноним Втр 29 Апр 2014 19:13:27  #66 №349079 

Какой смысл в этом TDD, если половину тестов придется переписывать при первом же рефакторинге?

Аноним Втр 29 Апр 2014 19:22:40  #67 №349085 

>>349045
С нихуя сделать вывод да еще и настолько промахнуться - это просто сказка какая-то. Теперь я окончательно убедился в твоей упоротости.

Аноним Втр 29 Апр 2014 19:26:30  #68 №349089 

>>349079
Нихуевый у тебя такой рефакторинг и изменением половины внешних интерфейсов. Если меняются публичные интерфейсы объектов - значит поменялись требования и их выполнение должно, очевидно, тестироваться по другому. Если же ты от нихуя неделанья взял и всё поменял - то извините, вам поможет только живительная эвтаназия.

Аноним Втр 29 Апр 2014 19:35:05  #69 №349095 

>>349089
> половины внешних интерфейсов.
То есть TDD только на внешние интерфейсы распространяется?

Аноним Втр 29 Апр 2014 20:14:56  #70 №349112 

>>349095
Ну как бы да, приватные методы, например, не тестируются, это детали реализации. Тест тестирует то, что доступно миру, а внутри ты хоть цирк коней пригласи.

Аноним Втр 29 Апр 2014 20:37:37  #71 №349124 

>>349112
Хуй знает. По-моему утверждение, что вся архитектура сразу же пишется по спецификации и потом не рефакторится, это какие-то выдумки борщехлобов-теоретиков. Или сотрудников всяких НАСА.

Аноним Втр 29 Апр 2014 20:44:53  #72 №349128 

>>349124
Понятно, что интерфейсы будут меняться и от этого никуда не деться, тем более в зачаточной стадии проекта, но тесты то тоже без фанатизма надо писать: если ты набрасываешь прототип модуля в отдельной ветке и сам еще ни в чем нихуя не уверен, то и тесты, очевидно, писать смысла нет.
Плюс, как ни странно, мне тесты перед написанием уже не прототипного кода помогают реже потом изменять публичные вещи, т.к. сама суть тестов подразумевает модульность и изолированность, что приводит к довольно сильной выверенности и четкости внешних интерфейсов.
Алсо, никакий спецификаций у меня обычно нет, просто обозначают конечную цель. Иногда согласовываем некоторые моменты взаимодействия с кодом других программистов.

sageАноним Втр 29 Апр 2014 20:46:47  #73 №349130 

блювать хоху(

Аноним Втр 29 Апр 2014 20:57:34  #74 №349137 

>>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

Аноним Втр 29 Апр 2014 21:10:31  #75 №349144 

>>348065
>Что покрывать в первую очередь?
Твою мамку

Аноним Втр 29 Апр 2014 22:06:17  #76 №349172 

>>348918
Лучше скажи нам, братюнь, как ты пишешь и как долго живут твои лабы? Приходилось ли тебе поднимать сырки софта, написанного год-два назад и начинать дорабатывать его? Менять предметную область?
Или ты как Чак Норрис - Ctrl+S и деплой?

Аноним Втр 29 Апр 2014 22:08:52  #77 №349175 

>>348941
Для логики на сервере юнит-тесты не помешают. А вот как тестить вьюхи, я хз.

Аноним Втр 29 Апр 2014 22:11:49  #78 №349178 

>>349079
Тесты покажут где и что сломал твой рефакторинг и надо ли было его проводить. Если все тестирование заключается в мышкой клац-клац и деплой, то да - от тестов толку ноль.

Аноним Втр 29 Апр 2014 22:54:44  #79 №349194 

>>349175
http://en.wikipedia.org/wiki/Behavior-driven_development

Аноним Втр 29 Апр 2014 23:19:45  #80 №349213 

>>349172
У Чака Норриса автосохранение + хук на автосохранении деплоит в случае успешного билда.

Аноним Втр 29 Апр 2014 23:38:04  #81 №349223 

>>349213
У него разве могут быть не успешные билды?? Анон, беду накликаешь.

Аноним Втр 29 Апр 2014 23:47:43  #82 №349229 

И ни один не написал о том, что TDD вообще-то способен драйвить архитектуру, способствовать улучшенной инкапсуляции и прочее и прочее. В команде абизян это сильно способствует орднунгу. Тру стори, никролль.

Аноним Втр 29 Апр 2014 23:49:15  #83 №349230 

>>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.

Аноним Втр 29 Апр 2014 23:58:12  #84 №349236 

>>349229
Про инкапсуляцию ты чой-то непонятное пукнул, поясни. Насчет орднунга - двачую. Тесты (у меня) почти всегда определяют рамки, согласованные с заказчиком - софтина должна работать так и никак иначе. Все остальные свистоперделки - в следующий релиз и следующее ТЗ.
Если после постановки ТЗ начинать с тестов, а потом загонять в их рамки логику, то и сроки не сорвешь и попаболи меньше. Особенно попаболи меньше, когда получаешь следующее ТЗ на доработку - можно сразу понять сколько времени это займет и что из существующего ломается.

Аноним Срд 30 Апр 2014 00:29:29  #85 №349256 

>>349230
Да-да, все это уже 100 лет назад обсосали и если только ты не донор мозга, ты будешь иметь это ввиду.
>>349236
Ну что тебе непонятно? Что, ты не видел случаи, когда логика размазана на 2-3 сервиса\класса\ватэвер, шарят данные друг с другом и инициализируют по цепочке друг друга с конфигов, пути которых вколхожены прямо в класс и подобную хуету? Приходишь, криком поясняешь про юнит тест, и тут, вдруг, криворукого озаряет, что чтобы написать тест ему надо инициализировать кучу говна, подложить в какие-то левые места конфиги и тому подобное. И начинается рефакторинг просто чтобы нормально тест к этому говну написать.

Аноним Срд 30 Апр 2014 00:46:29  #86 №349264 

>>349256
Криком надо пояснять, что сперва тест и интерфейсы сервисов, а только после Impl этих сервисов. Нах писать и натягивать тест на существующий говнокод с "вколхоженным" в него говном?

Аноним Срд 30 Апр 2014 00:50:24  #87 №349266 

>>349264
Я не тим лид, я просто кричать не боюсь.

Аноним Срд 30 Апр 2014 01:02:09  #88 №349271 

>>349266
Смысл-то не меняется - тесты в таком случае нужно только галочки и красивого coverage, но реально толку от них ноль.

Аноним Срд 30 Апр 2014 12:12:16  #89 №349395 

>>349264
On a side note: как же меня бесит джавовские naming conventions типа HuiPizda, AbstractHuiPizda, HuiPizdaImpl. В дудке вот нормально придумали: IHuiPizda, AHuiPizda, HuiPizda. В исходника Clojure, например, используется дотнетовский подходи к именованию, хоть там и жаба.

Аноним Срд 30 Апр 2014 12:14:47  #90 №349396 

>>349395
Это твои проблемы, остальным - норм. Хлебни лучше борща.

Аноним Срд 30 Апр 2014 12:32:45  #91 №349398 

>>349395
Мне в дудке нэйминг больше нравится, но именование мемберов с заглавной буквы у меня вызывает кровавые слёзы.

Аноним Срд 30 Апр 2014 13:01:31  #92 №349403 

>>349395
>В дудке вот нормально придумали
В джаве тоже дохуя либ, где используется такое же наименование.
>>349396
>Хлебни лучше борща.
Двачую этого адеквата. Глупо жаловаться на то, что ональные хозяева тебе на говно вишенку не так положили. Возьми нормальный борщеязык, и там будет и продуманый нейминг и всё прочее, и можно будет смело пиздеть в конфочках на разработчиков, если тебе что-то не понравится.

Аноним Чтв 01 Май 2014 00:40:31  #93 №349554 

>>348776
А если код рефакторнуть? Придется все тесты перепиливать? Это ж охуеть как время разработки увеличит. Нахуя всё это?

Аноним Чтв 01 Май 2014 02:38:20  #94 №349569 

Сейчас работаю над одним проектом на C++ без стандартной библиотеки. Написал свой небольшой фреймворк для юнит-тестов.
Пишу TDD - написал тесты, оно не компилируется. Написал прототипы методов/функций - компилируется, но не линкуется. Написал сами функции - тесты пройдены - ШИН. Можно порефакторить, запустить тесты и посмотреть, что по прежнему все работает.

Аноним Чтв 01 Май 2014 02:39:51  #95 №349571 
1398897591449.jpg

>>349172
>Чак Норрис
>Ctrl+S
>не :w

Аноним Чтв 01 Май 2014 04:07:36  #96 №349581 

>>349569
>ад одним проектом на C++ без стандартной библиотеки
UEFI?

Аноним Чтв 01 Май 2014 04:21:21  #97 №349583 

>>349581
Не, так одна штука для универа.

Аноним Чтв 01 Май 2014 07:46:40  #98 №349586 
1398916000319.png

>>349571
>:w
>2014
>не ZZ
нахуй пошёл

Аноним Чтв 01 Май 2014 07:48:41  #99 №349587 

>>349586
ZZ это :wq, а не :w

Аноним Чтв 01 Май 2014 07:51:10  #100 №349588 
1398916270343.jpg

>>349587
Кто то ещё пользуется вимом для чего то кроме как правки одной строчки в конфиге?

Аноним Чтв 01 Май 2014 07:53:30  #101 №349589 

>>349588
Пользуюсь для питонячьего, C, C++ кода. Планирую попробовать перекатиться на Emacs с evil'ом, когда будет время. или на neovim, если там нормальную многотредовость забацают

Аноним Чтв 01 Май 2014 07:57:00  #102 №349590 
1398916620981.jpg

>>349589
давно пора
не пытайся эмулировать вим в имаксе, ничего не выйдет. учи сразу

Аноним Чтв 01 Май 2014 07:58:48  #103 №349591 

>>349590
Учить сразу контролокомбинации и приобретать emacs pinky? Нет, спасибо. Уж лучше я все же попытаюсь осилить единственный нормальный текстовый редактор для имакса - evil.

Аноним Чтв 01 Май 2014 08:00:58  #104 №349592 

>>349591
Включай [cua,winner]-mode и будет заебись

Аноним Чтв 01 Май 2014 08:05:46  #105 №349593 

>>349592
Мне нравится модальное редактирование.

Аноним Чтв 01 Май 2014 08:08:24  #106 №349594 
1398917304326.jpg

>>349593

Аноним Чтв 01 Май 2014 08:09:56  #107 №349595 
1398917396070.png

Алсо по теме. Прошел через все стадии и в итоге пришел к смеси BDD, TDD и простого юнит тестирования. Зависимость есть, брат жив.

Аноним Чтв 01 Май 2014 08:10:42  #108 №349597 
1398917442829.jpg

>>349594

Аноним Чтв 01 Май 2014 08:11:39  #109 №349598 
1398917499417.png

>>349597

sageАноним Чтв 01 Май 2014 13:12:34  #110 №349632 

>>349588
Да.

Аноним Чтв 01 Май 2014 13:14:58  #111 №349636 

>>349597
лол, ctrl-болезнь
посмотрел, а у меня на клавиатуре только левый ctrl и есть
всё, имакс не светит мне ':-#

Аноним Чтв 01 Май 2014 14:10:26  #112 №349645 

>>349137 http://cpputest.github.io вот мой, отлично подходит для няшной сишки с железками.

Аноним Чтв 01 Май 2014 15:55:41  #113 №349680 

>>349597
А что не так с пальцем?

Аноним Чтв 01 Май 2014 17:34:49  #114 №349707 

>>348065
Какой профит от этого говна? Что реально можно проверить юнит тестом, кроме как сравнить два int'a или две строки? Давайте реальные примеры, а не Я ПРАЧИТАЛ ЧТО TDD ЕТА МОДНА, УСТАНОВИЛ БИБЛИОТЕКУ И ТЕПЕРЬ ПРОВЕРЯЮ, ЧТО ДВА РАВНО ДВА ЕТА КРУТА Я У МАМЫ КРУТОЙ ДЕВЕЛОПЕР))

Аноним Чтв 01 Май 2014 19:55:49  #115 №349749 

>>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)
})
Аноним Чтв 01 Май 2014 19:57:17  #116 №349750 

>>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()
})
Аноним Чтв 01 Май 2014 20:27:17  #117 №349759 

>>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
}
`

Аноним Чтв 01 Май 2014 22:16:15  #118 №349793 

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

Аноним Чтв 01 Май 2014 23:08:19  #119 №349817 

>>349759
Даже лень объяснять.
Ты просто видимо не писал сложные приложение и не знаешь как инкапсулированная логика внезапно может разрастись до космической сложности и такие очевидные, казалось бы, атомарные тесты, помогут тебе избежать фейла в дальнейшем.
Естественно, в форме не fieldOne и fieldTwo, а набор заведомо неизвестных полей и механизм, с помощью которого форма с ними работает внутри может постоянно изменяться.

Аноним Птн 02 Май 2014 12:05:37  #120 №349890 

>>349588
Vim рулит когда по SSH на сервере нужно что-то поправить. Программить локально с помощью Vim-а так и ниасилил - пробовал, но, блять, это как кактусы жрать и улыбаться при этом.

Аноним Птн 02 Май 2014 13:06:23  #121 №349903 

Адвентисты Седьмого Теста

Нет ну реально заебали. Вконец. Блядская секта, похуже хрестанутых. Что характерно, в секте состоит в основном всякая тупая копчёная индусня и прочие говноеды. При этом они считают всех не разделяющих их пидорастическую религию убогими, жалкими и недостойными называться программистами.

Я понимаю что объяснять что то фанатикам бесполезно, но всё же. А вдруг. Почему тесты говно? Тут есть несколько причин.

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
Аноним Птн 02 Май 2014 15:42:47  #122 №349926 

>>349903
Ну и нахуя он с этими недоумками в одном проекте работает, раз такой Д'Артаньян? Жрёт говно и жалуется, охуеть. Любой подход можно довести до маразма, тоже мне, Америку открыл.

Аноним Птн 02 Май 2014 16:38:39  #123 №349934 

>>349890
что именно неудобно?

>>349903
>Я не шучу - 99% тестов выглядят примерно так и несут такую же пользу. Очень жаль, тупое говноедище (см. ссылку выше) закрыло все свои посты, там был реальный пример функции которая возвращал толи захардкоженую строку, толи к ней прицепляла параметр, чота такое. И адовые тесты на это с использованием каких то дичайших либ чота там делающих с байткодом и прочим пиздецом. Я не шучу.
Наверное это очень важная функция, которая возвращает какой-то id, использующийся в проекте, тогда имеет смысл делать отдельный тест на генерацию этого id, чтобы было видно, если функция его генерации сломалась (если кто-то решил переписать её). Вполне нормальная ситуация.

>3. Они дают ложное ощущение безопасности. Тесты прошли? Хуяк-хуяк и в продакшн. Ничего же плохого случиться не может. Кстати, вариант что тесты не учитывают все случаи или содержат ошибку не рассматривается вообще. Никогда. Когда с ебанашками пытаешься говорить на эту тему у них та куча поноса больного бешенством кенгуру, которая заменяет им мозг, начинает бурлить и никакого конструктивного диалога не получается.
Ну это просто они - ебанашки, тесты ведь не виноваты в этом?

>4. Они отучают программистов думать. Нахуя думать если есть тесты? Тесты прошли - всё заебись. Не прошли - будем подгонять код под тесты. Этот пункт коррелирует с предыдущим. Нет смысла как то ещё проверять код при пройденных тестах (ну в смысле это пидорасики так считают).
Вообще-то они должны думать о слабых местах и когда пишут сам код, и когда пишут тесты. Тесты как раз и нужны, чтобы описать все слабые места, чтоб потом можно было сделать те же проверки для подправленного кода - но, конечно не факт, что этих проверок достаточно для проверки подправленного кода, но можно хотя бы, читая тест, посмотреть, что именно проверяли раньше и подумать что можно ещё проверить.

>5. Замечена закономерность. Чем больше тестов - тем меньше отладочных логов. А вот как разбираться с дейтсвительно хуёвым случаем когда раз в неделю в продакшне рандомно идёт по пизде целостность данных? Тесты тут ничем и никогда не помогут. Ну и да - тестами нереально оттестировать что нибудь сложное, когда 100500 процессов/потоков и данные хуярят гигабайтами в минуту.
Где такая закономерность? У ебанашек? :3

>Ну вот как то так. Возникает закономерный вопрос: чо, тесты не писать? Да нет - писать. Только правильные, функциональные, тесты. То есть пустить тестируемое приложение, накормить его реальными данными, дёрнуть типичные вокфловы и сравнить полученный результат с эталонным.
Не всегда удобно писать функциональные тесты, но когда их можно написать достаточно просто - конечно стоит. Но от всех тестов есть своя польза, и от юнит-тестов, и от интеграционных тестов, и от функциональных тестов. Правда надо оценивать, можно ли их написать достаточно эффективно, т.к. пишу код 5 минут, а потом тест целый день - это хуета и не нужно. Нормальный workflow - пишу тестик, что мне надо от функции, пишу заглушку, которая его не проходит, правлю её код до функции, которая тест проходит, возможно добавляю test case-ы, которые были не очевидны до написания функции. Но такое удобно для сетевого кода, например, или для работы с данными, а для программирования UI - не годится.

>PS. Я реально в одном проекте видел тесты к тестам. Натурально. Моя жизнь уже никогда не будет прежней.
А в чём, собственно, проблема? Надо же периодически проверять, что тесты не сломались - если это можно делать автоматически - то здорово! Остаётся проверить вручную только тест к тестам :3

Аноним Птн 02 Май 2014 17:45:19  #124 №349942 

>проверить вручную только тест к тестам
Никогда нельзя останавливаться,
но прозреваю рекурсивные тесты.

Аноним Птн 02 Май 2014 17:54:57  #125 №349944 

>>349942>>349934
И внезапно идея, которая витала в воздухе.
В банках часто используют метод двух персон.
Еще там стараются делать тайный метод двух персон,
так что каждая сторона не знает, где другая.

Я это к чему.
У нас есть некое нечто, имеющее состояние (например, записи в БД). У нас есть тест, который переводит некую вещь из состояние 1 в противоположное состояние 2. И у нас есть тест, делающий обратное преопразование. Делаем третий тест, который херачит вот такое 1-2-1-2-1 и 2-1-2-1-2, сверяя одинаковость происходящего, используя первые два теста. Идеально, если все три херотни лежат в разных модулях. И разрабатываются в разных компаниях.. извините, я не могу сдержать смех и печатать дальше

Аноним Птн 02 Май 2014 23:46:26  #126 №350042 

>>349942
тру - осознать бесконечность через рекурсию

Аноним Суб 03 Май 2014 06:22:26  #127 №350096 

>>349554
>А если код рефакторнуть? Придется все тесты перепиливать? Это ж охуеть как время разработки увеличит. Нахуя всё это?

код рефакторится при помощи встроенных в ide средств.

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

Аноним Суб 03 Май 2014 08:54:54  #128 №350101 

> когда используешь TDD изначально, получается хорошая арихтектура и код

Всё совсем наоборот.
То что ты отделяешь интерфейс от реализации и формализуешь требования к коду вообще не гарантирует что код и архитектура не будут говном. А из-за того, что такие долбоёбы как ты, думают, что при использовании ТДД ПО само становится качественным, всё только хуже получается.

В тдд ты сначала пишешь тесты и делаешь так, чтобы они выполнялись, похуй как, потом если есть время, это говно рефакторится. Это такая философия, что иногда действительно можно забить на красоту в угоду ЛИЖБЫРАБОТАЛО. Это называется аджайл.

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

Аноним Суб 03 Май 2014 09:59:21  #129 №350108 

>>350101
Изо дня в день проигрываю в этом треде. Диванные эксперты объяснят вам, что писать тесты - это вам не головой думать, это пальцы сами пишут. Так же, в порыве капитанства они уведомят вас о том, что тесты по умолчанию не гарантируют высокого качества кода, а потом упомянут "так, чтобы они выполнялись, похуй как", будто ты бы это что-то новое, а не принцип, старый как мир: "сделай, чтобы работало -> сделай красиво -> сделай быстро" и даже в сторону этого тезиса они начнут бросаться какашками, пребывая в полном неведении о том (а как узнать то, если не тестируешь, а вещаешь с дивана), что человек, привыкший выделять правильные абстракции (а без этого не научиться писать хорошие тесты) напишет "чтобы работало" намного качественней, чем макака, привыкшая писать код, как бог на душу положит, но "думая головой".

Аноним Суб 03 Май 2014 11:01:10  #130 №350125 

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

Ты какой-то ебанутый, правда же.
Моя логика:
1) Если ты будешь писать тесты, ты научишься писать тесты и протестируешь своё приложение, избавишься от всяких глупых и случайных ошибок.
2) Если ты будешь писать код думая головой, ты научишься писать более качественный код.

Твоя логика:
Если ты будешь писать тесты, ты будешь выделять правильные абстракции, отвыкнешь писать код "как бог на душу положит", получишь хорошую архитектуру и код.

Тут блядь всё просто, или, по-твоему, качество кода является прямым следствием написания тестов или нет.
Если нет, то какая нахуй разница, писал ты тесты или нет. У плохого программиста тесты будут такими же некачественными как и его код.

Аноним Суб 03 Май 2014 11:45:09  #131 №350137 

>>350125
Давай просто уточним один момент перед продолжением разговора (а то такое ощущение, что ты выхватываешь процентов десять информации из моих постов) - ты юнит-тесты пробовал писать на настоящих проектах недельку другую хотя бы?

Аноним Суб 03 Май 2014 12:13:51  #132 №350144 

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

Аноним Суб 03 Май 2014 22:23:04  #133 №350310 

Стоит ли при использовании TDD рефакторить сами тесты? Как православно это делать?

Аноним Вск 04 Май 2014 00:58:24  #134 №350351 

>>350310
Не просто стоит, в этом весь смысл!

Аноним Вск 04 Май 2014 11:20:32  #135 №350405 

>>350310
Нет. Блядь, с какого хуя у тебя внешнее поведение меняется, если ты рефакторишь?

Аноним Вск 04 Май 2014 11:46:15  #136 №350407 

>>350144
Не понял, а зачем ты их пишешь, если тебе не нравится?
Приведи, пожалуйста, пример типичного теста, который вы пишете в конторе. А лучше пару тройку.

Аноним Вск 04 Май 2014 13:02:32  #137 №350421 

>>350405
Какое нахуй внешнее поведение, ты о чем вообще?

Аноним Вск 04 Май 2014 14:42:59  #138 №350435 

>>350310
Надо писать тесты к тестам.

Аноним Вск 04 Май 2014 15:41:45  #139 №350442 

>>350421
Поведение, которое ты, блядь, тестируешь.

Аноним Вск 04 Май 2014 21:58:10  #140 №350541 

>>349934
>что именно неудобно?
Привык пользоваться IDE-шными плюшками вроде "Introduce variable", "Extract Method/Field", "Inline", "Refactor this", psvm, sout,...

Наверное можно обмазаться всем этим в vim-е, но зачем?

Аноним Пнд 05 Май 2014 15:57:26  #141 №350713 

ООП,
Паттерны,
Юниттесты,
ТДД,
Тесты к тестам,
Тесты к тестам тестов,
Тесты к тестам тестов тестов

...

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

comments powered by Disqus

Отзывы и предложения