а я вот что понял

[juan_gandhi]

Я первый год в Америке кюеем работал. В те поры девелоперы тестов не писали, это им было западло. И я валял кучу всяких тестов (большинство пойманных мной багов пережили крах Борланда, и теперь живут на небесах). Но следующие шесть лет в Борланде я имел репутацию Этого Странного Кюея. Это там была порядочная толпа идиотов (ну, какие полиформизмы бывают, не знают, но спорить с ними бесполезно, т.к. ты Странный Кюей, а он аж Старший Инженер). Хрен с ними; была и масса больших талантов. Некоторые из них сейчас в колледжах преподают программирование, а кто-то в автогонщики подался; кто-то умер; одна пошла выучилась на врача.

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

Не, я не предлагаю ссылать в кюеи на год (да и дураков нет, они пойдут в другую контору, где их будут ценить). Но чисто для себя.

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

Comments

[spamsink]

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

[dijifi]

Эт точно.
Тут есть оргвопрос — тестовый отчет это ведь только исходная информация для принятия решения о качестве продукта, а не окончательный вердикт.

[dijifi]

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

[fatoff]

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

[juan_gandhi]

Это тебе везет.

[vak]

В моём нынешнем проекте правило: новый код не коммитится, если не покрыт тестом. Дабавили фичу - добавили тест. Уже больше двух тысяч тестов за два года.

[vit_r]

Покрытие тестами -- это не гарантия того, что код работает правильно. Это просто надежда на то, что программист сделал, что хотел.

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

[redis]

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

Впрочем, полгода поработал тестером, история тоже связана с США, но иначе. У нас тогда был контракт с IBM, и они перепутали количество наших девелоперов. Те, за кого не заплатили, были на полгода переведены в тестеры с сохранением зарплаты. Первое время я тестировал собственный софт, чего делать, в общем-то, нельзя.

Я быстренько всё автоматизировал, после чего быстренько всё сделал и попросил еще. Не дали, зато в конце месяца попало за ничегонеделанье

[juan_gandhi]

Красивый подход. Знакомый. В колхозе на картошке такое случалось у меня.

[sidorovmax]

Какой продукт в Борланде тестировали?

[juan_gandhi]

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

[elglin]

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

[beldmit]

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

Но как же ломы! Ну и когда я ловил вот это, у меня был высокоуровневый тест совершенно неудобоваримого вида — но низкоуровневый коллегам, уже знавшим, что ловить, пришлось писать едва ли не больше, чем мне искать проблему. А если усилия не пропорциональны, то очень тяжко.

К счастью, QE тут у нас на полуавтономке, а на низком уровне в Red Hat писать мне не нужно.

[dennisgorelik]

В Microsoft разработчики начинали с позиции Software Development Engineer in Test (SDET).
Вероятно, одной из важных причин - было привить привычку тестировать свой код.

[fatoff]

Те, которые изначально были наняты SDET. А вообще-то скорее нет, чем да.

[norian]

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

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

[juan_gandhi]

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

[vit_r]

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

[juan_gandhi]

О! Сдал и забыл. Вот оно.

[chaource]

Но следующие шесть лет в Борланде я имел репутацию Этого Странного Кюея.
А почему "странный кюэй"? Въ чёмъ была странность? Тестировать кодъ это же и есть задача кюэевъ.

На моей теперешней работѣ я въ группѣ единственный, кто настаиваетъ на тестахъ съ 100% code coverage, и кто пишетъ кодъ для тестированiя сложныхъ баговъ, а не тестируетъ вручную, что багъ пофиксенъ, послѣ деплоя вручную на staging environment, какъ любятъ дѣлать нѣкоторые наши друзья изъ солнечной Индiи.

[juan_gandhi]

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

[ppk_ptichkin]

Меня этому научили в Dassault в 2000м году. Без unit tests код отвергался, и всё. Дальше там уже были integration tests, multiplatform, и т.д.

Мне, конечно, повезло, что они нас купили. Где бы ещё я этому (и ещё много чему) научился.

[vap]

У меня отношение к тестам странное, кощунственное. Я не считаю, что юнит-тесты вообще следует писать для любого кода, кроме сильно абстрактного. По сути, юнит-тест проверяет, что код работает так, как он должен работать по мнению того, кто писал тест. И если код и тест писал один человек - то и смысл теста теряется. Если я не просек, что в задаче есть особый случай - я и в тесте его не проверю.
Исключений из этого моего мнения два: первое - когда код сильно абстрактный и действительно нужно проверять соответствие реального поведения предполагавшемуся. И второе - когда программист знает за собой склонность писать методом тыка, "а если здесь поправить - может, заработает? Не, совсем сломалось. А если здесь?"
К тому же, юнит-тесты ловят только баги в функциональности и тупые падения. А вот нарушения инвариантов - не ловят. Например, если после итерации теста не вся память возвращена - юнит-тест это не поймает, для такого нужно всякие валгринды использовать. И так во всем. А ведь эти баги как раз и есть самые мешающие.

[ppk_ptichkin]

Есть третий вариант. Ваш код, включая тесты, просматривают ещё несколько человек.

[sassa_nf]

The most important aspects of design are about how you are going to find out what lead to a failure.

[juan_gandhi]

Good observation. In AI/DS/ML it's not required.

[ernestine_16]

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

[ratomira]

Девелопер - это тот, кто написал программу, то есть программист. Кюэй - это тестировщик программы, тестирует, чтобы программа работала. Баг - это ошибка (в программе). Примерно как-то так.

[epimorphisms_split]

Хочу иногда пойти преподавать программирование в колледж. Как посмотрю иной раз на этот код... С другой стороны, никто же не сказал, что получится преподать что-нибудь путное. И денег мало дают.

[zakrit_dver]

Я не знала, что за океаном тестировщиков называют кюэями. Расшифруйте, плиз.

[dijifi]

QA, quality assurance, уверенность в качестве

[dijifi]

Этот Суровый Архангельский Странный Кюэй выглядел а глазах Старших Инженеров как ситуация в этом баянистом анекдоте:

Купили как-то суровым сибирским лесорубам японскую бензопилу.
Собрались в кружок лесорубы, решили ее испытать.
Завели ее, подсунули ей деревце.
«Вжик» — сказала японская пила.
«У, бля...» — сказали лесорубы.
Подсунули ей деревце потолще. «Вж-ж-жик!» — сказала пила.
«Ух, бля!» — сказали лесорубы.
Подсунули ей толстенный кедр. «ВЖ-Ж-Ж-Ж-Ж-Ж-Ж-ЖИК!!!» — сказала пила.
«Ух ты, бля!!» — сказали лесорубы.
Подсунули ей железный лом. «КРЯК!» — сказала пила.
«Ага, бля!!!» — укоризненно сказали суровые сибирские лесорубы! И ушли рубить лес топорами

https://lurkmore.to/%D0%A1%D1%83%D1%80%D0%BE%D0%B2%D1%8B%D0%B5

[dluciv]

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

[anonim_legion]

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

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

Проблема с интеграционными тестами в том, что если внешняя система сделана поверх микросервисов на монге, то ответы внешней системы могут быть неустойчивы. Особенно когда у внешней системы нет чётко известного набора ответов. В тесте её запросил - она работает, а на проде ИНОГДА у заёмщиков есть пометка, что данные об их сбережениях получены через Plaid, а вот самого ответа от Plaid ещё нету. И надо устраивать опрос в цикле, с задержками, в течении скажем 5 минут. И это не единственные данные, которые могут не придти, стало быть нужно иметь какой-то глобальный механизм повторов, и ещё избежать случая, когда несколько разных событий меняют одни и те же выходные данные одновремннно. Сейчас у меня оно сделано через AWS SQS FIFO, но тесты на такое опять же не напишешь, тут надо какую-то модель делать, не знаю на чём, присматриваюсь к http://verdi.uwplse.org , но это тяжело.

Или например из внешней системы приходят данные, где имеется поле даты. Потом внезапно и без предупреждения в этом же самом текстовом поле вместо даты появляется TBD, to be defined, разумеется чтение из модели на этаких данных начинает падать. Стало быть, нужно теперь читать это поле как строку, проверять не TBD ли там, и если да, то в выходной модели ставить флажок DateXXXIsTBD, а если не TBD, то читать дату и на этом месте уже падать - если там таки не дата.

А ещё бывает такое: некий лендер возжелал, чтобы все запросы кредитных историй шли через их собственный сервис, а они сами уже будут эти запросы проксировать скажем в MeridianLink, или ещё кому, в зависимости от содержания запроса. У них там в ответе внутри JSON прилетает строка, а в ней мегабайтного размера XML, причём JSON-escaped, но это ещё ладно. Сервис этого лендера иногда не отвечает на запросы. То есть, к ним запрос ушёл, и висит, ждёт, по 20-30 секунд на каждого человека, по которому были запрошены данные, как обычно. Вообще так делать не положено, долгие запросы в HTTP, но они делают. Так запрос ушёл - а ответа нет. Что же делать? Можно считать, что запрос был неуспешен и вернуть в результате задания ошибку.

Но в сервисе лендера считают, что у них всё работает, и предлагают запрашивать их ещё раз. Хорошо, делаем цикл, время ожидания ответа - 70 секунд, потом пауза в 10 секунд при неудаче и ещё один запрос, и так 5 раз. Всё заработало! Не с первого раза, так с пятого. Это оказалось проще, чем заставить лендера чинить их сетевые проблемы. Тем более, что проблемы может быть вообще не у них.

Теперь иногда лендер жалуется, что они на одного человека делают по 5 soft pull кредитной истории подряд. На моё предложение ввести некую распределённую блокировку на их стороне, где ключом будут данные людей из запроса, и вместо запуска нового запроса - отдавать мне результат старого, или же подключать меня к ожиданию текущего - это предложение было как-то вот проигнорировано.

Юнит-тесты - это хорошо. Когда вы работаете с алгоритмами, которые обрабатывают статические данные. Иначе такие тесты теряют смысл. И не такие - тоже.

В прод.

[juan_gandhi]

"Но в сервисе лендера считают, что у них всё работает, и предлагают запрашивать их ещё раз. Хорошо, делаем цикл, время ожидания ответа - 70 секунд, потом пауза в 10 секунд при неудаче и ещё один запрос, и так 5 раз. Всё заработало! Не с первого раза, так с пятого. Это оказалось проще, чем заставить лендера чинить их сетевые проблемы. Тем более, что проблемы может быть вообще не у них."

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

Ну и чо, и я нарисовал Retry, с policy, которая может выбрана юзером (программистом), или может быть стандартной, с ростом задержки в sqrt(2), до определенного количества попыток. Все это мы проходили еще при имплементации протокола ZModem.

[uselessextras]

А вот еще недавний пример. Ногами не бейте только.
Имеем C++:
class blah-bla {
f(string)
f(string, string)
...
Юнит тесты есть. Работает в продакшн лет 20.

Надо добавить еще параметр, и чтобы много не переписывать, даем ему умолчание:
f(string, bool = false)
f(string, string, bool = false)

В древнем коде находится такое место:
f("one", "two")

Век живи, век учись, тестами покрыть один фиг хрен сможешь.

Параметр по умолчанию

[dennisgorelik]

> Надо добавить еще параметр

Зачем "надо добавить еще параметр"?
Может быть лучше добавить отдельный метод, чтобы не создавать путаницы с использованием уже написанных методов?
Этот новый метод может вызывать уже существующий метод, без изменения существующего метода.

> f("one", "two")

Здесь есть какой-то баг?

[dijifi]

А используем ли мы одинаковую терминологию? Википедии верить не советую.

Типов тестов до хрена, и каждая организация/тусовка вкладывает свой смысл.
Даже я могу с ходу накидать: unit functional conformance regression integration verification validation acceptance и даже quality (как в WHQL).

По моему старому опыту (2000е) иногда приходится перенастраиваться: например юнит-тесты в одном проекте должны бвли проходить при каждой компиляции, и это для кода который обычно бегает а контексте ядра операционки. Это значит: каждый тест (а их десятки тысяч) должен занимать микросекунды; в ядре нельзя гонять, надо а юзере, значит все едреные апи надо мокать; организованно должно быть в билде практически как фаза компиляции. Результат — программисту приходится думать о том, что компилятор мог бы найти, но не может по причине своей тупости.

Компилятор и тесты

[dennisgorelik]

> программисту приходится думать о том, что компилятор мог бы найти

Можете привести пример того, что компилятор "мог бы найти"?

[http://users.livejournal.com/sorcerer-/]

Большинство юнит тестов бесполезны. Про это есть отличная статья:
https://rbcs-us.com/documents/Why-Most-Unit-Testing-is-Waste.pdf

Лучше всего писать e2e и regression.
Неплохо: integration.
Все остальное - карго культ.
С изобретением тулзов, допамин от зеленых отметочек пересиливает рационализм.
Основная проблема большинства современных компаний - это "pr-driven development", где из-за засилья бесполезных тестов невозможно разрабатывать код локально (пробежки на лэптопе слишком долгие или незасетаплены нормально) вот с этим тоже надо бороться. Ну и конечно адовейшая фикция - это "полное покрытие", т.к. в общем случае покрытие нельзя посчитать. Хочешь что-то "полное" - юзай фаззеры, но фаззеры 99% не осиливают внедрить.

[juan_gandhi]

Прочитал эту смешную демагогию.

Вот я писал код для разной интуиционистской логики, для построения топологий. И чо, не писать тесты? Очень смешно. Мне нужны были тесты. Конечно, для передачки содержимого формочек... да и то иной раз следует.

И вот начинаются рассуждения, "у вас данные неверные, поэтому у меня вышел NPE".