Две статьи про юнит-тестирование.

[Max Lapshin]

Статьи немного провокационные, так что просьба поспокойнее к ним относится.
Однако, написано достаточно предметно.

http://blogs.msdn.com/cashto/archive/2009/03/31/it-s-ok-not-to-write-unit-tests.aspx
http://fallenrogue.com/post/234250827/re-its-ok-not-to-unit-test-or-what-you-do-on-your

В первой ссылке упоминается про тулзу Jester, которая умеет мутировать
код и прогонять его по юнит-тестам, что бы
можно было оценить, насколько код не покрывается тестами. Она основана
на http://ruby.sadi.st/ Так же советую посмотреть.

[Max Lapshin]

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

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

[Alexey Verkhovsky]

2009/11/6 Max Lapshin <max.l...@gmail.com>

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

У тех кто умеет - не превращаются.
 

--
Alexey Verkhovsky
http://alex-verkhovsky.blogspot.com/
CruiseControl.rb [http://cruisecontrolrb.thoughtworks.com]

[astashov]

А вот ещё мнение из третьего лагеря: Армстронг о тестировании в
Эрланге.
http://armstrongonsoftware.blogspot.com/2009/01/micro-lightweight-unit-testing.html

[oleg dashevskii]

Вопрос про тестирование интересный. Как отслеживать положительность ROI при написании тестов? :)

6 ноября 2009 г. 17:01 пользователь Max Lapshin <max.l...@gmail.com> написал:

--
Олег.

[Fedor Kocherga]

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

On Nov 6, 2009, at 1:56 PM, Max Lapshin wrote:

> Статьи немного провокационные, так
> что просьба поспокойнее к ним
> относится.
> Однако, написано достаточно
> предметно.
>
> http://blogs.msdn.com/cashto/archive/2009/03/31/it-s-ok-not-to-write-unit-tests.aspx
>
>

> В первой ссылке упоминается про тулзу
> Jester, которая умеет мутировать
> код и прогонять его по юнит-тестам,
> что бы
> можно было оценить, насколько код не
> покрывается тестами. Она основана
> на http://ruby.sadi.st/ Так же советую
> посмотреть.
>

--
Fedor Kocherga
fkoc...@gmail.com

[Alex Grigorovich]

2009/11/7 Fedor Kocherga <fkoc...@gmail.com>:

> Абсолютно согласен с точкой зрения про
> assert-ы. Почему то мало распространенная
> практика среди рубистов. Да и лишь
> лишний раз убедился, что лучше время
> потратить на более высокоуровневые
> тесты чем на юнит тестирование.

"Integration tests are a scam"

Integration tests are a scam—a self-replicating virus that threatens
to infect your code base, your project, and your team with endless
pain and suffering.

Видео: http://www.infoq.com/presentations/integration-tests-scam

Серия блог-постов:
http://www.jbrains.ca/category/named/integration-tests-are-a-scam

[Max Lapshin]

Всё таки это какая-то очень болезненная тема вообще — контроль качества.
Сколько людей, столько мненией насчет разнообразных форм тестирования.

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

Сходятся, пожалуй, все в одном: ручное тестирование ничем не отменить.

[Fedor Kocherga]

On Nov 8, 2009, at 10:53 AM, Alex Grigorovich wrote:

"Integration tests are a scam"

Integration tests are a scam—a self-replicating virus that threatens
to infect your code base, your project, and your team with endless
pain and suffering.

Видео: http://www.infoq.com/presentations/integration-tests-scam

   

   Чтобы ни у кого не сложилось впечатление, что J.B. Rainsberg стоит в ярой оппозиции к интеграционым тестам глядя на эти фразы, я все же рекомендую просмотреть видео полностью и прочитать его блог. У кого нет времени на это (а его речь на видео занимает 1.5 часа.), то вкратце его логическая цепочка такова:

Интеграционные тесты  долгие, а это значит долгое время реакции на ошибку, а поэтому народ сокращает и либо выполняет их частично либо вообще не выполняет, что приводит к ложному чувству уверенности что все хорошо. А чего они такие долгие - то? А потому что до выполнения первого assert-а необходимо подготовить кучу всего, а он приверженец того, что один тест должен содержать один assert, потому что количество упадших тестов будет отображать состояние системы, а если за одним assert-ом прячется другой, то поправив первый мы можем натолкуться на второй и т.д., вобщем неизвестно сколько работы предстоит и в каком все состоянии находиться. Но assert–ов хочется понатыкать побольше, т.к. велик объем подготовительной работы был сделан для них, поэтому выходит, что assert-ы у разных тестов перекрываются. Да и подготовительная работа дуплицируется. Для двух тестов она может перекрываться на 90%, но для всех перекрытие 0.  Да и вообще сколько можно написать тестов? Ну 2000. А комбинаций путей кода которые надо проверить - миллоны. И как в лотерее, что покупая 10 билетов, что 10000 шансы все равно остаются почти никакие, так и в тестировании интеграционными  тестами количеством сильно делу не поможешь. Потом он говорит такую (очень правильную на мой взгляд) мысль, что и нечего использовать интеграционные тесты для проверки именно корректности работы. Они для другого служат, они для кастомеров, а для именно проверки работы приложения служат другие тесты. (В этой части речи я подумал, ну вот сейчас дальше он будет говорить про изолированное тестирование с помощью моков, в общем ничего нового для руби программистов, к тому же обильное использование моков дает такое же чувство ложной уверенности от которого он пытался уйти, тесты проходят а система не работает). Ну и действительно, он стал рассказывать про моки, но продвинулся далее, и сказал что действительно мокая что либо, надо задаваться вопросом а имеем ли мы право это мокать, т.к. мы делаем предположения о методах и возвращаемых результатах, а так ли эти предположения обоснованы? Ну и действительно, эти предположения надо проверять, а поэтому наряду к этим тестам, которые он назвал "коллоборационными" надо писать дополнительные, которые он назвал "контрактными", которые проверяют действительно ли то, чего мокают ведет себя таким образом как ожидается. (При этом, кстати, он как то опускает вопрос подготовки этих самых систем для тестирования, хотя конечно очевидно, что работы на их подготовку в изоляции на прокачку "контрактов" потребуется меньше чем для интеграционных тестов). Ну и далее утвеждает, что хоть не может доказать, но изоляционные тесты плюс "коллоборационные" плюс "контрактные" достаточны на 100%  для проверки корректности системы. Хотя правда неудобно то, что каждое использование мока требует комплиментарного "контрактного" теста, и это своего рода избыточность, вот если бы это можно было автоматизировать - то PHD на подобного рода работе можно спокойно сделать.

Интересно еще его блог почитать, там он показывает, как с помощью его метода, можно было бы поймать ситуацию когда марсоход не примарсился из за того, что его дернуло парашютом в момент раскрытия и система приземления сработала на это как на толчок о поверхность марса и отцепила парашют. Там интересно почитать ход его мысли выраженной в псевдокоде, но понятно, что пиши он "коллаборационные" тесты без "ability to notice things", то подобный печальный сценарий вполне можно было бы и пропустить. У меня сложилось ощущение, что интеграционным тестом он бы был "скорее" пойман, даже на этапе "happy path", когда все шло без эксцессов.

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

Ну и прошу не записывать меня в абсолютные пропоненты интеграционного тестирования, я ранее употреблял слово "более высокоуровневые" чем юнит тесты, вобщем J.B. Rainsberg тоже говорит о более высокоуровневых. Просто вреда от неправильно сделанных локальных вещей меньше, чем если что либо не сходится на высоком уровне.  

--

Fedor Kocherga

fkoc...@gmail.com

[Maxim Kulkin]

On 08.11.2009, at 16:19, Fedor Kocherga wrote:
> Интеграционные тесты долгие, а это
> значит долгое время реакции на
> ошибку, а поэтому народ сокращает и
> либо выполняет их частично либо
> вообще не выполняет, что приводит к
> ложному чувству уверенности что все
> хорошо.

У нас в продукте большая часть тестов -
интеграционные (из-за характера самого
продукта). Большой упор сделан на то,
чтобы каждый разработчик имел
возможность запускать тесты на своей
машине (или на dev box'е). Но большую часть
тестов разработчики не запускают: как
правило при комите разработчик сам
определят, какие тесты затрагивают его
изменения и выполняет только их. НО! У
нас есть continuous integration сервер, который
периодически прогоняет все тесты.
Поэтому утверждение о том, что
интеграционные тесты ничего не
поймают, потому что их никто не
запускает для нас не применимо: да,
всех их никто не запускает, но каждый
день мы собираемся и втыкаем в логи CI
сервера, по которым сразу видно, если
что-то сломалось.

[Max Lapshin]

Мысли, конечно, интересные, но то, чем занимается подавляющее
большинство из нас, имеет мало отношения к задачам типа марсохода. Для
контроля качества кода марсохода существует активно развиваемая
последние 40 лет методика доказательного программирования,
единственная дающая 100% гарантию качества кода.

Она развивается в сторону отхода от 100% к 99,999.... и какие-то вроде
наработки существуют.

Однако, я не встречал ни одного внятного объяснения подхода «один
тест-один ассерт».

[Alex Nickolaenkov]

А не из-за DRY?
Если предполагать, что каждый тест тестирует что-то свое и в нем
делается 1 assert, то каждое изменение обрушит только 1 тест.
С дублированием, а несколько ассертов на тест обычно это
подразумевают, валиться может несколько тестов сразу при изменении
чего-то одного.

08.11.2009, в 18:06, Max Lapshin написал(а):

> Однако, я не встречал ни одного внятного объяснения подхода «один
> тест-один ассерт».

Алексей Николаенков
mail, jabber, g-talk:
nickol...@gmail.com

[Max Lapshin]

2009/11/8 Alex Nickolaenkov <nickol...@gmail.com>:

> А не из-за DRY?
> Если предполагать, что каждый тест тестирует что-то свое и в нем
> делается 1 assert, то каждое изменение обрушит только 1 тест.

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

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

[Alex Nickolaenkov]

Понятно, что в реальности все несколько сложнее.
Я клоню к тому, что идеальные примеры TDD, где все так замечательно
подсказывают, что в идеале должно быть так. Т.е. 1 тест — 1 ассерт
похоже на достижимый в редких случаях идеал. Этим можно объяснить
почему все твердят, что надо на 1 тест — 1 ассерт. Примерно тоже самое
что рекомендуют делать при работе за компьютером каждый час перерыв на
15 минут.


08.11.2009, в 18:18, Max Lapshin написал(а):

mail, jabber, g-talk:
nickol...@gmail.com