![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
juan_gandhi) wrote2021-12-10 07:54 pm
а я вот что понял
Я первый год в Америке кюеем работал. В те поры девелоперы тестов не писали, это им было западло. И я валял кучу всяких тестов (большинство пойманных мной багов пережили крах Борланда, и теперь живут на небесах). Но следующие шесть лет в Борланде я имел репутацию Этого Странного Кюея. Это там была порядочная толпа идиотов (ну, какие полиформизмы бывают, не знают, но спорить с ними бесполезно, т.к. ты Странный Кюей, а он аж Старший Инженер). Хрен с ними; была и масса больших талантов. Некоторые из них сейчас в колледжах преподают программирование, а кто-то в автогонщики подался; кто-то умер; одна пошла выучилась на врача.
Так вот только недавно я начал понимать, какой это был (бес)ценный опыт. Потому что обычные программисты, без опыта тестирования - они вроде юзеров. Тыкают пальчиком, вдруг заработает.
Не, я не предлагаю ссылать в кюеи на год (да и дураков нет, они пойдут в другую контору, где их будут ценить). Но чисто для себя.
Ну это как, пойдя в матросы, лучше научиться уже плавать, заранее, а не когда на море качка.
Regression testing
Нет, не теряется.
Unit test продолжает тестировать покрытый код.
И ловит ситуации, когда какое-то изменение привело с тому, что этот unit test - fails.
> если после итерации теста не вся память возвращена - юнит-тест это не поймает,
> эти баги как раз и есть самые мешающие
Memory leaks - are hard to diagnose. But they do not necessarily prevent application from working.
Re: Regression testing
И ловит ситуации, ловля которых предусмотрена автором кода и теста. То есть, заведомо и так отсутствующие в любом коде, более-менее активно используемом в работе. Но продолжает не ловить ситуации, которые автор кода не предусмотрел.
Я еще пойму fuzzy-тестирование, там хотя бы проверяются инварианты поведения на большой выборке случайно выбранных тест-кейсов. Но обычные юнит-тесты могут выполнять только роль регрессионных (но для этого они слишком подробны, регрессионные тесты должны быть повыше уровнем, потому что все интересные регрессии происходят не внутри модулей, а на стыке).
Re: Regression testing
Вот именно, что ловит.
А без unit tests - не ловит. И ранее найденные и исправленные баги - могут появиться снова.
И, по закону бутерброда, появляются.
> обычные юнит-тесты могут выполнять только роль регрессионных
1) Основная цель юнит тестов - regression testing.
2) Есть и другие цели.
Например, написанный unit test - облегчает тестирование при модификации кода.
В unit test документируются примеры разных ситуаций, с которыми должен работать основной (тестируемый) код.
> регрессионные тесты должны быть повыше уровнем
Регрессионные тесты могут быть повыше уровнем.
Но регрессионные тесты полезны и на низком уровне.
> все интересные регрессии происходят не внутри модулей, а на стыке
Нет, не все.
Внутри модулей тоже бывают интересные регрессии.
Особенно если модули сложные.
Re: Regression testing
Да с юниттестами еще важный момент - краевые и негативные случаи. Что будет, если передать null или отрицательное число участников, и т.д.
Unit tests for null and negative values?
На мой взгляд, эти случаи нужно описывать в тестах только в том случае, если дизайн основного метода предполагает возврат осмысленных значений при передаче null (или отрицательного) значения параметра.
Re: Unit tests for null and negative values?
Если мы хотим писать надежный код, контактирующий с джавой, то такие кейсы надо программировать всегда. Чтоб не было, когда юзер в форме написал какую-нибудь фигню, а ему за это HTTP 500 ("мы сломались")
Re: Unit tests for null and negative values?
Каким образом "фигня в форме" может превратиться в null?
Даже если HTTP POST не содержит нужного нам поля, валидатор формы вполне может поймать такое событие.
А если валидатор формы не разрешает null значения, то зачем в методу, который сохраняет в базу данных - добавлять test case for null?
Re: Unit tests for null and negative values?
А, запросто. В форме поле для даты, юзер написал "TBD", софт пытался распарсить, и, по обычаю джавщиков, вернул null.
И вставлять или не вставлять, зависит от того, что мы тестируем. Но тема интересная. Рассчитывать, что все наши параметры адекватные? Я не возражаю, если просто бросать исключение. Ну так и проверим, бросит, или вернет, в ответ на null, дату обрезания Иисуса Христа.
Re: Unit tests for null and negative values?
Если мы ожидаем null, как один из нормальных результатов - придется писать код для этого случая.
И расширять unit test [with null value test case].
> Рассчитывать, что все наши параметры адекватные? Я не возражаю, если просто бросать исключение.
Именно так: если метод не поддерживает какой-то диапазон - throw exception.
Тогда и unit test для такого случая не нужен.
И если этот exception случается - значит нужно дописывать код.
Re: Unit tests for null and negative values?
"Бросать эксепшен" - это только одно из возможных решений. Вполне приемлемое, но не единственное. Но ты ж не знаешь, оно бросит эксепшен или вернет дату обрезания Христа.
Re: Unit tests for null and negative values?
Да, но только если это неожиданное событие произойдет.
> или вернет дату обрезания Христа
Кто "вернет дату обрезания Христа"?
Re: Unit tests for null and negative values?
Программа. Дату не распарсили, возвращаем 01.01.0001.
Re: Unit tests for null and negative values?
Обычно лучше, если программа throws an exception если распарсить не получается.
Либо какой-нибудь сигнал о том, получилось ли распарсить.
Re: Unit tests for null and negative values?
Да уж всяко лучше.
Re: Unit tests for null and negative values?
Re: Unit tests for null and negative values?
The obvious fix is to extend functionality to support that new date edge case (years 2000+).
Re: Unit tests for null and negative values?
Re: Unit tests for null and negative values?
I suggest to throw in case of null [as a default choice in version 1 of the software].
> if you don't test that the method throws on invalid inputs, you are in the same boat as Y2K
1) If I have throwing code, the "throw" part is likely to work even if I do not have unit tests that check for that "throw" behavior.
2) Being "in the same boat as Y2K" -- is not the worst place to be.
That software with Y2K holes in it -- generated a lot of revenue over 10-30 years prior to Y2K event.
Re: Unit tests for null and negative values?
"generated a lot of revenue" - like! (but not 30 years prior, not even 20)
Re: Unit tests for null and negative values?
Do you mean that almost no software that was working in 1999 was written prior to 1980?
Re: Unit tests for null and negative values?
30 years prior to Y2K
Re: Unit tests for null and negative values?
Let's check it 16 years from now.
Re: Unit tests for null and negative values?
Re: Unit tests for null and negative values?
We sure will. Passing around dates as longs is ubiquitous.
Re: Regression testing
+1 очень часто на тестах демонстрирую как работать с кодом, особенно, во всяких POC полезно.
Unit tests for prototyping
Да: прототипы вызывающих методов в unit test-ах тоже удобно писать.