Тесты реально полезны?

Конечно же нужно уметь писать тесты, как автономные, так и интеграционные

писать тесты для своего кода на XUnit.

тестирование (юнит и мок),

ну юнит тесты какие-нибудь писать можно в конце концов

Раздел про тестирование на этом форуме, считай что отсутствует, так что тут поинтересуюсь - тесты реально полезны?

Ну т.е. не с психологической точки зрения, мол, так на душе спокойнее, а именно с практической?

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

Сейчас вот читаю очередную книжку, рекомендованную qwerty.123, но с реальностью оно пока не особо стыкуется .

0

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

4

kotelok, за корпоративную разработку ничего не скажу, но для своих проектов, как по мне, проще всего написать тест-генератор входных данных и поставить на ночь. пока ты спишь - умная машинка генерирует лог, если он пустой, то вроде как и отлично, а если кривой и косой, то самое тут важное - по конкретной ошибке ты имеешь выгрузку входных данных. чем-то напоминает Leetcode, когда запускаешь задание на 3-5 тестов и всё отлично, а запускаешь на 80 - а там косяк и сиди изучай что там не так. Чаще всего вылавливаются простейшие ошибки типа где-то -1 или +1 или какие-то пограничные случаи. Бывает генератор по сложности раза в три-четыре больше чем сама программа. Но в целом пишу такое где-то в 20% случаев.

1

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

1

Тесты топ

0

Сообщение от kotelok Но вот, скажем, завтра я обращусь к руководству и предложу выделять мне на каждую задачу в 2 раза больше времени

Как-то дофига, если честно. Есть конечно случаи когда тикет делаешь 1ч, а тесты 2ч, но обычно наоборот.

"Переубедить руководство" -- это не ко мне. Бизнес это в первую очередь про деньги, а не инженерные решения. Плюс нужно смотреть вашу кодовую базу, если там всё взаимосвязано и писать тесты по мере поступления задач не шибко получится -- навряд получится внедрить. Максимум написать общие тесты для автоматизации регрешен и забить.

Сообщение от kotelok В этот проект, кстати, по сей день изменения/дополнения вносятся. Ну бывает с багами. Но оно всё быстро выявляется/фиксится.

Ну вот для ускорения правок, тесты и пишутся. Да это дорогое удовольствие, которое могут себе позволить только компании, которые пишут продукт "в долгую перспективу". Гипотетически возможная история:

Есть метод Sum, который изначально только делал A + B. Написали простейший тест аля 1 + 2 expected 3.

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

Проходить 5 лет, приходит правка "считать логарифм последовательности мнимых чисел корня из 17 в промежутке от А до лимита окружности квадрата В". Для начала ты офигиваешь что твой метод из одной строчки превращается в сотню-другую. Потом начинаешь дэбажить, потому что не понимаешь почему закинул (1, 2), ожидаешь 5, а получаешь -4. Если нет теста -- дэбажить на запущенном проекте? Порой один только старт занимает минут десять.

Проходить день, тестер "при значении 1, -3 ожидаем 7, а возращает -5". Ты в отпуске/запое/бегах. Колега открывает код, а там чёрт ногу сломит. Долго вдупляется в формулу, меняет пару моментов и ему теперь нужно заново протестировать что ничего не сломал. Логика НЕ менялась, пришёл баг. Старые значения 100% должно отрабатывать. Если человек по наивности и неопытности влепил фикс наугад чисто для случая описаного в тикете -- остальные тесты не пройдут. А если ещё и выливка в мастер ветку только с одобрения пайплайна -- то ещё и не зальёшь эту фигню в основной код. Добавить кейс (1, -3, expected 7) -- секунда дела. При тестировании QA прогонит только значения 1, -3 и может ещё одно. Его тоже дрючат "чего там много времени на плёвую задачу тратишь?"

P.S. всё это круто, когда поставлено на поток со старта. Когда уже есть проект, и нужно привести к такому состоянию.... Это как делать ремонт в старой панельке: отдираешь обои и почему-то падает потолок.

1

Вставлю и я свои "5копеек" на эту тему.

1. Не на любой код можно "натянуть" unit-тесты. Поэтому тесты помогают писать "правильный" код (использовать ООП).
2. Unit-тесты особенно полезны когда на проектом работает группа разработчиков, потому что "охраняет" ваш код от "несанкционированных изменений".
3. Unit-тесты "охраняют" ваш CI/CD от случайных изменений. Сделали правки, без тестов запустили на "боевой" сервер, в процессе публикации тесты не прошли - публикация не случилась - благодать!
4. Всё покрывать unit-тестами - не эффективно. Я покрываю тестами только значимые для бизнес-логики механизмы или около нее (бизнес-локики) функциональность. Покрывая всё - велика вероятность "свалиться" в "эмуляцию вселенной" для unit-тестов.
5. Вот серия видео роликов про Unit-тестирование. Делал давно, но актуальность не утеряна.

3

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

иногда случается большая удача и есть какой-то стандарт/спецификация как что-то должно работать тогда вообще удается писать снала тесты а потом код. (но такое бывает не всегда).

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


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

1

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

P.S. Скорее всего он "не видит" по той причине, что не умеет писать реально полезные тесты, а не тесты ради тестов: таким заявлением он сразу себя выдаёт и это сразу идёт ему в "минус" на собеседовании. В этом случае будет лучше просто признаться в том, что нет опыта в написании тестов - в этом нет ничего зазорного, а разобраться в теме на приемлемом уровне можно будет достаточно быстро.

1

Сообщение от kotelok Не понятно, что именно мне даст тест.

- боже мой... Вот есть программа. Готовая, работающая. Кто даёт гарантию, что она (программа) выдаёт верные результаты? Пусть, для алгоритма, по которому составлена программа, это доказано (алгоритм верен). А кто/что гарантирует, что программа соответствует алгоритму?
Программист "зуб даёт"? Но от этого толку немного...

Существует только один способ доказать, что программа верна - провести её верификацию. Фактически это означает "доказать теорему о том, что данный программный код соответствует алгоритму". Понятное дело, что это - очень сложный путь. И верификации подвергаются далеко не все производимые программы.

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

Пользоваться программой, которая не тестировалась, это всё равно, что сесть в автомобиль, про исправность тормозной системы которого ничего не известно.

Теперь понял, что даёт тестирование?

2

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

Сообщение от kotelok Но вот, скажем, завтра я обращусь к руководству и предложу выделять мне на каждую задачу в 2 раза больше времени, т.к. я решил весь код тестами покрывать. И как мне обосновать снижение моей продуктивности в два раза? Что в качестве реального аргумента привести?

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

Сначала всё же считаю стоит чётко понимать что тесты бывают разные и делать их соответствено приходится по разному. К этому я шёл долго, но только потому что видимо не хотел этого принять. А вот о чём
- юнит тесты - это ОООЧень простые тесты. Тест одного уровня. Если это метод сервиса, то не нужно чтобы полноценно работали остальные методы других сервисов. Их надо "мокать". Мы должны проверить как работает метод (или сервис) - что вошло и что вышло.
- если задействованы другие сервисы - это уже скорее интеграционный тест. Его делать по ощущениям выгоднее - мол проверяет всю цепочку от запроса до результата. Но тут и начинаются настоящие проблемы. Мы должны полноценно создать все сервисы, создать чуть ли не натуральное окружение, и если что-то упадёт, то мы будем ловить просто ошибку и потом разбираться что и почему упало (ну то есть как в обычной ситуации отладки).
! Совет. Вот тут и надо понять - что от вызова до результата будет множество точек (сервисы, методы, ..) где и должны проверяться входные данные и результат. Вот их и надо превращать в юнит тесты и тестировать независимо.

Цель тестов:
- стадия разработки (то то что писал Wolfdp): быстро проверить работу метода.
Намного проще запускать тест метод, чем запускать всё приложение, протыкивать UI, вводить значения и ждать когда наконец-то отработает метод. Входные данные - результат. Всё.
- поддержка: если кто-то изменит код, который повлияет на результат.
Разумеется зависит от масштаба зависимости метода. Известный, "side effect". Если метод идеально-функциональный, то в целом можно полагаться. Но как только в нём используется что-то из вне. Да даже какой-то статический метод который что-то складывает и вычитает. ВСЁ, считай у тебя уже есть причина чтобы недоверять результату. И поэтому кто-то может поправить ДРУГОЙ метод, но результат изменится у тебя. От этого мы и защищаемся.
! Сразу же пишем юнит тесты на эти внутренние методы, чтобы и за них быть уверены.
- документирование. Вот к этому я тоже пришёл давно и очень этому рад.
Есть методы имя которых говорит всё о том что они делают. Но всё равно недостаточно и возникают сомнения что они возвращают или не сломаются ли они на каких-то условиях. И тогда достаточно Взглянуть на тесты, чтобы понять что они делают и на какие ситуации они заложены.
Я поддерживаю легаси проект. И когда я решился обложить тестами такие методы, то потом пил безбожно с радостью заканчивал тест, в котором было проверено много из известного и немного из того что я нашёл в процессе написания теста.
У меня есть тесты где есть заведомо странный результат, который сразу можно причислить к багу. Но как оказалось это "скрепы" сервиса. Вот так это работает и на это завязаны другие сервисы (поэтому я не стал даже рефакторить). Но! теперь в тесте это Наглядно видно.

- рефакторинг. (это сразу в продолжении документирования). Вынесу это в отдельный абзац, так как это тоже полноценная тема. В процессе рефакторинга внезапно оказывается что некоторые методы не покрыты тестами. Начинаешь их делать, а оказывается что ты ДАЖЕ Не понимал как сервис работал. То есть начинается вырисовываться вся картина. И это чудесная ситуация чтобы сделать рефакторинг кода приложения.
Зачастую тесты приводят тебя к выводу - что твой код говно. А точнее - он не тестируем. И это почти тема для филосовских рассуждений о ООП и коде вообще. Потому что, оказывается, что чтобы тесты работали - нужно создать больше абстракций, раскидать на сервисы, делать более простые параметры, использовать меньше зависимостей и т.п. и т.д. А почему? А потому что когда ты пытаешься протестировать какой-то один метод, внезапно оказывается что тебе надо замокать десяток сервисов, десяток методов, разобраться почему там такой результат а не такой как ты ожидал и... в итоге получаешь не ожиданный результат. А почему? а потому что оказывается что даже твой сервис ожидал другие данные.
И я обожаю рефакторинг, это как глубже и лучше понимать что и как взаимодействует и распутывать клубок.
- рефакторинг 2 (обратная ситуация)
Очень часто я сталкиваюсь с другой ситуацией. Я вижу что тест очень сложный и непонятный - это "звоночек" что и сервис работает так же непонятно. И когда начинаю внимально смотреть - оказывается что можно тут переписать, тут вытащить, туда перетащить... и внезапно проходит чуть ли не масштабный рефакторинг на 3 сервиса, но код становится в разы проще и понятнее. Часто уничтожаются ненужные зависимости или сервисы.

- рефакторинг 3. Это когда обновляется сервис а у тебя не было теста, ну или он был но простой. То что писал Рядовой.
Например, пришло ТЗ на изменение поведения сервиса, причём логика сильно меняется. Например, у меня есть данные которые хранятся в XML. А сейчас я решил переписать их на JSON. Но код например должен поддерживать оба варианта или иметь обратную совместимость. Источник не поменялся, выходные данные должны быть теми же.
Мы должны сначала написать/иметь тесты тестирующие текущую ситуацию. Тесты должны быть "зелёными". Зафиксировать этот вариант. А потом писать тесты на новый формат. И снова чтобы они были "зелёными". (как-то так.. плохой пример но надеюсь понятный)

Часто я делаю Простые тесты.
Это значит что если был создан новый сервис на какой-то функционал. То, в завимости от вашего перфекционизма вы можете заморочаться за его полноту. Но лучше помнить о том что - Невозможно покрыть 100% тестами всё приложение. Но можно по мере того как вы "трогаете" код, набивать приложение тестами, даже простыми.
Простой тест - это значит что в новыом методе теста есть основная проверка на то что вы ожидали видеть на входе и выходе. И на этом бросаете. Зачем такое можно использовать? Для дальшейшего улучшения. Как только вы ловите проблему - у вас уже есть точка где можно добавить проверку на эту ситуацию. Типа "ленивый режим" - создавать новый тест сложно, а добавить условие - это легко. Добавить может уже любой программер, который например будет задачу с закрытие бага закрывать.

Сообщение от kotelok В практической пользе. Не понятно, что именно мне даст тест. Есть ТЗ на метод, есть реализация, реализация делает то, что требуется. Всё ок. Ну можно тест добавить. Ок, будет метод с тестом, будет потрачено время на реализацию теста, метод продолжит так же работать, как и до теста.

Прочитал и не понял. Что за ТЗ на метод? Обычно бывают ТЗ на какой то функционал. А методы которые реализуют этот функционал - это ты реализуешь, вот их и проверять.
Что такое "метод продолжит так же работать, как и до теста."? Разумеется когда ты пишешь тест - он обычно работает. Он нужен для защиты от изменений (кто-то уже писал). Когда кто-то поправил код и результат поменялся, тогда тест и отработает.

Добавлено через 4 минуты

Сообщение от kotelok Ну т.е. не с психологической точки зрения, мол, так на душе спокойнее, а именно с практической?

Долго искал примеры, чтобы не сильно сложный и не сильно NDA код

Вот пример. Метод который логирует строку подключения к БД. По ТЗ нужно чтобы он скрывал пароль. Есть статический метод. Вот его и тестируем. Набил столько вариантов сколько смог сам придумать. Если будут найдены ситуации - будем добавлять (см. выше) или исправлять. Но главное я пока что уверен в том что в логах не будет утечки паролей.

Ещё вспомнил. Я давно пришёл к выводу что писать тесты не должны программисты. В идеале это должны быть тестеры.
Почему? Да потому что (см. выше код) программист Знает как работает его код и ему Сложно написать с ошибкой.
Поэтому если нет тестеров или они не пишут вам код, то вся надежда на ревьювера. Идеальный ревьювер
- загрузит ветку
- проверит тест всё равно (даже если вы скажете что всё работает)
- незамыленным взглядом может придумать ещё варианты

3

Сообщение от Catstail А кто/что гарантирует, что программа соответствует алгоритму? Программист "зуб даёт"? Но от этого толку немного...

Для условного руководителя проекта или аналитика, который принимает решение, что ок, можно в прод, нет вообще никакой разницы между:
"Вот зуб даю, всё ок!" (с) программист.
И:
"Вот зуб даю, всё ок, я там ещё тест написал!" (с) тот же программист.

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

0

Сообщение от kotelok Потому как тест писал ровно тот же программист с теми же багами в голове, с тем же особым пониманием задачи.

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

2

Сообщение от kotelok Потому как тест писал ровно тот же программист с теми же багами в голове, с тем же особым пониманием задачи.

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

Добавлено через 2 минуты
И если тест не пройдет, будет одна резолюция: "Не работает. Переделывай." Причем не вдаваясь в детали.

2

Сообщение от kotelok Потому как тест писал ровно тот же программист с теми же багами в голове

- в приличных фирмах этого не бывает. Тестировщик - это отдельная фигура. Основной принцип тестирования: автор программы (написавший её) тестировщиком быть не должен. Это азбучная истина. Зря споришь.

2

Сообщение от Catstail - боже мой...

сколько энергии ) только примите как данность что для большинства программ (в количественном выражении) никто тестами не занимается или занимаются не в должном объеме (или вы никогда не видели changelog'и и bugfix'ы от разработчиков?). Так что руки тут заламывать нет смысла. Лично я - плохой пример, но всё же, за 35 лет всё что мной писалось никогда не тестировалось и проблем в работе программ было исчезающе мало. Но за последние года три тесты как таковые наоборот стали для меня предметом интереса, но там особенность софта такая, это тесты алгоритмов.

0

Сообщение от Catstail Тестировщик - это отдельная фигура. Основной принцип тестирования: автор программы (написавший её) тестировщиком быть не должен.

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

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

0

belalugoci, в настоящее время реалии несколько иные: тестируется практически все, даже там, где этого не надо. Такова текущая 'данность'.
Те же тесты проверки вариантов решений на вашем рекламируемом highload.fun - тоже люди писали. Или вы думаете что ваш вариант проверял реальный человек?

Сообщение от kotelok без этого навыка вообще низкие шансы даже на джун-вакансию попасть.

Я бы сказал, что это один из наиболее важных навыков - уметь тестировать свой код. Даже если ты сам уверен в нем на 100% - нужно показать это другим.

1

Сообщение от wizard41 Я бы сказал, что это один из наиболее важных навыков - уметь тестировать свой код.

Сообщение от Catstail Тестировщик - это отдельная фигура. Основной принцип тестирования: автор программы (написавший её) тестировщиком быть не должен.

Ну ок .

0

Сообщение от belalugoci Лично я - плохой пример, но всё же, за 35 лет всё что мной писалось никогда не тестировалось и проблем в работе программ было исчезающе мало.

- а что делали эти программы?

0

0