Является ли залогом безбажности тщательная проверка всего кода, и что делать, если в нашей команде — является?

Question

[vzyalgvozd]

Эпиграф. Буквально час назад написал код из 70 строчек, в котором при первой перепроверке нашел 3 бага, при второй - еще 1, а при третьей - еще 1. Последний был алгоритмическим - я в цикле изменял то, по чему идет этот же цикл. И такое постоянно.

Ранее у нас были релизы, кишащие в общем-то багами.

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

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

1. Так, как думаете, в релизе багов действительно не будет?
2. Может, вообще не писать авто-тесты? Ведь по трудоемкости проще посмотреть что-то в коде, чем написать тест на этот кейс. Или писать их только на сложное, то есть не делать их юнит-тестами, строго говоря.

Answer 1

[tester12]

И то, и другое. И ручная проверка кода (не своего, а коллеги), и тесты.

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

Comments

[vzyalgvozd]

и порой на тщательную ловлю багов нет времени.

А не для этого ли нужны трудоголики, которые днем что-то попишут + ночью перед днем релиза половят баги тщательно?))
Что-либо писать у них не всегда получается, потому что они тупят из-за своей усталости, а вот ловить баги...
Например я за 3 месяца работы в проекте выучил все способы отключить будильник во сне не проснувшись... Куда бы я его ни засовывал - все равно отключаю... Это за счет того, что я почти что не спал 3 месяца. А только работал и искал баги.

Answer 2

[Владимир Коротенко]

1. баги есть везде
2. вы не понимаете логики тестов.

Тесты это не заумь их назначение проверка работы, то есть пишите их сначала, получаете красные значки. Дописываете код, тесты зеленеют. Причем этот код у вас есть всегда, он автоматически выполняется, не страдает невнимательностью и выдает четкое указание тут проблема.

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

Comments

[vzyalgvozd]

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

[Владимир Коротенко]

vzyalgvozd, Для этого есть дополнительные тесты, которые вводят после реальной ошибки.
Преждевременная оптимизация - корень всех бед (С)

Answer 3

[Евгений Ромашкан]

Эпиграф. Буквально час назад написал код из 70 строчек, в котором при первой перепроверке нашел 3 бага, при второй - еще 1, а при третьей - еще 1.

А как считаются строки? Если это 70 строк одной процедуры с циклами то это проблема.

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

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

А ещё стат. анализ, иммутабельность.

Так, как думаете, в релизе багов действительно не будет?

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

Может, вообще не писать авто-тесты? Ведь по трудоемкости проще посмотреть что-то в коде, чем написать тест на этот кейс.

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

Или писать их только на сложное, то есть не делать их юнит-тестами, строго говоря.

Вообще, посмотрите этот доклад - https://www.youtube.com/watch?v=VDfX44fZoMc .
И да, чтобы удешевить покрытие кода unit-тестами, нужно уменьшать связность в коде, иначе утонете в моках.
Улучшение проектирования - одна из основных задач unit-тестов(и основная задача при использовании tdd).

Comments

[vzyalgvozd]

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

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

[Евгений Ромашкан]

vzyalgvozd,

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

Примеры проблем где?
Может тесты пишутся таки плохо, потому и не ловятся.

Читать умеем?

Умеем. И исходя из прочитанного я вам ответ написал выше. Ваша очередь читать.

[vzyalgvozd]

Евгений Ромашкан, Ну баг с переполнением типа например. Как его выявить тестом? На переполнение тоже везде тесты писать?

[Евгений Ромашкан]

vzyalgvozd,

Ну баг с переполнением типа например. Как его выявить тестом? На переполнение тоже везде тесты писать?

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

P.S. Если проблема не выявляется ни запуском тестов ни запуском программы, может не такая уж это и проблема? Всё же, не шаттлы пилите.

Answer 4

[Saboteur]

2. Может, вообще не писать авто-тесты? Ведь по трудоемкости проще посмотреть что-то в коде, чем написать тест на этот кейс. Или писать их только на сложное, то есть не делать их юнит-тестами, строго говоря.

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

Поэтому автотесты - писать надо.

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