а я вот что понял
Dec. 10th, 2021 07:54 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
juan_gandhiЯ первый год в Америке кюеем работал. В те поры девелоперы тестов не писали, это им было западло. И я валял кучу всяких тестов (большинство пойманных мной багов пережили крах Борланда, и теперь живут на небесах). Но следующие шесть лет в Борланде я имел репутацию Этого Странного Кюея. Это там была порядочная толпа идиотов (ну, какие полиформизмы бывают, не знают, но спорить с ними бесполезно, т.к. ты Странный Кюей, а он аж Старший Инженер). Хрен с ними; была и масса больших талантов. Некоторые из них сейчас в колледжах преподают программирование, а кто-то в автогонщики подался; кто-то умер; одна пошла выучилась на врача.
Так вот только недавно я начал понимать, какой это был (бес)ценный опыт. Потому что обычные программисты, без опыта тестирования - они вроде юзеров. Тыкают пальчиком, вдруг заработает.
Не, я не предлагаю ссылать в кюеи на год (да и дураков нет, они пойдут в другую контору, где их будут ценить). Но чисто для себя.
Ну это как, пойдя в матросы, лучше научиться уже плавать, заранее, а не когда на море качка.
Regression testing
Date: 2021-12-12 05:26 pm (UTC)Нет, не теряется.
Unit test продолжает тестировать покрытый код.
И ловит ситуации, когда какое-то изменение привело с тому, что этот unit test - fails.
> если после итерации теста не вся память возвращена - юнит-тест это не поймает,
> эти баги как раз и есть самые мешающие
Memory leaks - are hard to diagnose. But they do not necessarily prevent application from working.
Re: Regression testing
Date: 2021-12-12 05:52 pm (UTC)И ловит ситуации, ловля которых предусмотрена автором кода и теста. То есть, заведомо и так отсутствующие в любом коде, более-менее активно используемом в работе. Но продолжает не ловить ситуации, которые автор кода не предусмотрел.
Я еще пойму fuzzy-тестирование, там хотя бы проверяются инварианты поведения на большой выборке случайно выбранных тест-кейсов. Но обычные юнит-тесты могут выполнять только роль регрессионных (но для этого они слишком подробны, регрессионные тесты должны быть повыше уровнем, потому что все интересные регрессии происходят не внутри модулей, а на стыке).
Re: Regression testing
Date: 2021-12-12 06:11 pm (UTC)Вот именно, что ловит.
А без unit tests - не ловит. И ранее найденные и исправленные баги - могут появиться снова.
И, по закону бутерброда, появляются.
> обычные юнит-тесты могут выполнять только роль регрессионных
1) Основная цель юнит тестов - regression testing.
2) Есть и другие цели.
Например, написанный unit test - облегчает тестирование при модификации кода.
В unit test документируются примеры разных ситуаций, с которыми должен работать основной (тестируемый) код.
> регрессионные тесты должны быть повыше уровнем
Регрессионные тесты могут быть повыше уровнем.
Но регрессионные тесты полезны и на низком уровне.
> все интересные регрессии происходят не внутри модулей, а на стыке
Нет, не все.
Внутри модулей тоже бывают интересные регрессии.
Особенно если модули сложные.
Re: Regression testing
Date: 2021-12-12 09:10 pm (UTC)Да с юниттестами еще важный момент - краевые и негативные случаи. Что будет, если передать null или отрицательное число участников, и т.д.
Unit tests for null and negative values?
Date: 2021-12-12 10:03 pm (UTC)На мой взгляд, эти случаи нужно описывать в тестах только в том случае, если дизайн основного метода предполагает возврат осмысленных значений при передаче null (или отрицательного) значения параметра.
Re: Unit tests for null and negative values?
Date: 2021-12-12 10:32 pm (UTC)Если мы хотим писать надежный код, контактирующий с джавой, то такие кейсы надо программировать всегда. Чтоб не было, когда юзер в форме написал какую-нибудь фигню, а ему за это HTTP 500 ("мы сломались")
Re: Unit tests for null and negative values?
Date: 2021-12-13 12:42 am (UTC)Каким образом "фигня в форме" может превратиться в null?
Даже если HTTP POST не содержит нужного нам поля, валидатор формы вполне может поймать такое событие.
А если валидатор формы не разрешает null значения, то зачем в методу, который сохраняет в базу данных - добавлять test case for null?
Re: Unit tests for null and negative values?
Date: 2021-12-13 01:55 am (UTC)А, запросто. В форме поле для даты, юзер написал "TBD", софт пытался распарсить, и, по обычаю джавщиков, вернул null.
И вставлять или не вставлять, зависит от того, что мы тестируем. Но тема интересная. Рассчитывать, что все наши параметры адекватные? Я не возражаю, если просто бросать исключение. Ну так и проверим, бросит, или вернет, в ответ на null, дату обрезания Иисуса Христа.
Re: Unit tests for null and negative values?
Date: 2021-12-13 02:24 am (UTC)Если мы ожидаем null, как один из нормальных результатов - придется писать код для этого случая.
И расширять unit test [with null value test case].
> Рассчитывать, что все наши параметры адекватные? Я не возражаю, если просто бросать исключение.
Именно так: если метод не поддерживает какой-то диапазон - throw exception.
Тогда и unit test для такого случая не нужен.
И если этот exception случается - значит нужно дописывать код.
Re: Unit tests for null and negative values?
Date: 2021-12-13 03:14 am (UTC)"Бросать эксепшен" - это только одно из возможных решений. Вполне приемлемое, но не единственное. Но ты ж не знаешь, оно бросит эксепшен или вернет дату обрезания Христа.
Re: Unit tests for null and negative values?
Date: 2021-12-13 12:45 pm (UTC)Да, но только если это неожиданное событие произойдет.
> или вернет дату обрезания Христа
Кто "вернет дату обрезания Христа"?
Re: Unit tests for null and negative values?
Date: 2021-12-13 07:42 pm (UTC)Программа. Дату не распарсили, возвращаем 01.01.0001.
Re: Unit tests for null and negative values?
Date: 2021-12-14 06:30 am (UTC)Обычно лучше, если программа throws an exception если распарсить не получается.
Либо какой-нибудь сигнал о том, получилось ли распарсить.
Re: Unit tests for null and negative values?
Date: 2021-12-14 02:57 pm (UTC)Да уж всяко лучше.
Re: Unit tests for null and negative values?
Date: 2021-12-13 08:03 am (UTC)Re: Unit tests for null and negative values?
Date: 2021-12-13 12:52 pm (UTC)The obvious fix is to extend functionality to support that new date edge case (years 2000+).
Re: Unit tests for null and negative values?
Date: 2021-12-13 01:20 pm (UTC)Re: Unit tests for null and negative values?
Date: 2021-12-13 01:39 pm (UTC)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?
Date: 2021-12-13 07:40 pm (UTC)"generated a lot of revenue" - like! (but not 30 years prior, not even 20)
Re: Unit tests for null and negative values?
Date: 2021-12-14 07:00 am (UTC)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?
From:30 years prior to Y2K
From:Re: Unit tests for null and negative values?
Date: 2021-12-13 07:41 pm (UTC)Let's check it 16 years from now.
Re: Unit tests for null and negative values?
Date: 2021-12-14 06:58 am (UTC)Re: Unit tests for null and negative values?
Date: 2021-12-14 02:56 pm (UTC)We sure will. Passing around dates as longs is ubiquitous.
Re: Regression testing
Date: 2021-12-12 09:35 pm (UTC)+1 очень часто на тестах демонстрирую как работать с кодом, особенно, во всяких POC полезно.
Unit tests for prototyping
Date: 2021-12-12 10:06 pm (UTC)Да: прототипы вызывающих методов в unit test-ах тоже удобно писать.