Комментарии 43
Привет, Дмитрий.
На мой взгляд статья слегка сумбурная. Судя по структуре, целью статьи было структурировать информацию об авто-тестировании. Но информация в пунктах зачастую приведена коротко, а некоторые высказывания спорные и требуют развития мысли.
Также не понял, для кого статья предназначалась. Если для новичков в теме, то снова возвращаемся к ее скомканности. Если для людей, которые в целом в теме, то столь подробная структура излишняя — она не несет ничего нового.
В общем и целом: статьи на Хабре по большей части я бы разделил на два виды. Либо статья описывает какую-то проблему и ее решение. Либо рассказывает подробно о чем-то (как что-то сделать, как чем-то пользоваться и т.д.). Данная статья не решает никакой заявленной в начале проблеме, но и на обучающую тоже не тянет.
Думаю, если найти все же время, в дальнейшем можно развить статью во что-то клевое. Успехов! :)
На мой взгляд статья слегка сумбурная. Судя по структуре, целью статьи было структурировать информацию об авто-тестировании. Но информация в пунктах зачастую приведена коротко, а некоторые высказывания спорные и требуют развития мысли.
Также не понял, для кого статья предназначалась. Если для новичков в теме, то снова возвращаемся к ее скомканности. Если для людей, которые в целом в теме, то столь подробная структура излишняя — она не несет ничего нового.
В общем и целом: статьи на Хабре по большей части я бы разделил на два виды. Либо статья описывает какую-то проблему и ее решение. Либо рассказывает подробно о чем-то (как что-то сделать, как чем-то пользоваться и т.д.). Данная статья не решает никакой заявленной в начале проблеме, но и на обучающую тоже не тянет.
Думаю, если найти все же время, в дальнейшем можно развить статью во что-то клевое. Успехов! :)
НЛО прилетело и опубликовало эту надпись здесь
Если же модулю нужны другие модули, то они заменяются заглушками и мы проверяем, что коммуникация с ними происходит как ожидается.
Это только если вы так решили. А можно, наоборот, подставить модуль, который ведет себя так, как ожидает тестируемый, и проверять поведение тестируемого.
Другое дело, что иногда цель модульного тестирования — это и есть проверка комуникации с зависимостями, и тогда без моков вы не обойдетесь.
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
То есть, по вашему мнению, от языка/экосистемы это никак не зависит?
Что же такого сложного в monkey patch в функциональном языке?
НЛО прилетело и опубликовало эту надпись здесь
"Это" — это сложность реализации monkey patching в тесте (и вообще сложность юнит-тестирования с использованием monkey patching).
НЛО прилетело и опубликовало эту надпись здесь
Тестирование это верификация работоспособности модулей на основе контрольных значений. Расстановка и обработка этих значений в ООП удобнее.
… вот только с monkey patching это все никак не связано.
НЛО прилетело и опубликовало эту надпись здесь
Для какого явления?
НЛО прилетело и опубликовало эту надпись здесь
Собственно, вы же и процитировали "другое название".
НЛО прилетело и опубликовало эту надпись здесь
Ну во-первых, если это можно сделать без monkey patch, то да, религия гласит, что лучше сделать без monkey patch.
Во-вторых, покажите, пожалуйста, как сделать monkey patch в .net для банального Stream.Length.
НЛО прилетело и опубликовало эту надпись здесь
Ну вот тогда и не утверждайте, что в ООП monkey patch идеален для тестирования объектов. Возможно, в каком-то известном вам языке/экосистеме — да. Но не в ООП в целом.
НЛО прилетело и опубликовало эту надпись здесь
Утверждаю — идеален на любом языке.
Утверждать-то вы можете что угодно, но вот только доказать это не можете.
Ибо язык собственно не причём.
И что же делать, если язык (точнее, среда выполнения) не позволяют monkey patching?
Утверждаю — идеален на любом языке. Ибо язык собственно не причём. Почитайте на досуге про верификацию компиляторов.
В зависимости от языка и среды исполнения вам придется или специально проектировать код для такого механизма или извратиться так, что усилия превысят разумые пределы.
У вас есть С++ — в добрый путь :)
в .Net тоже можно извратиться весьма сходно — но «цена» и сложность превысит сложность проверяемого кода.
маленькая стрелочка в последнем ряду так была и задумана?
на картинке вторая слева
на картинке вторая слева
Модуль или юнит — минимальный кусок кода, который можно протестировать независимо от всего остального кода. Тестирование модулей так же известно как «юнит-тестирование».
1. А насколько независимо от остального кода? какой критерий «независимо»? Например код типа «трансформация данных» или «парсер»/сериализатор/десериализатор к какому будет относится типу?
2. К какому типа будет относится проверка «workflow» если вопрос стоит «корректный да-нет»?
Unit -Component — Integration?
Локализация проблемы. Тест затрагивает лишь часть кода.
из своего опыта скажу что юнит тесты даже если покрывают 100% кода ещё не значит что отдельные компоненты будут работать вместе правильно, а ещё может быть избыточность действий когда разные модули слишком большие и они делают одно и тоже но немного по разному, либо вовсе не работают вместе, так может вместо юнит тестов писать сразу функциональные которые делают тоже что и конечный продукт в целом, тестов получается меньше проверяют они столько же, бегут правда помедленнее, но без них всё равно никак а 2 раза тестировать сначала юнит потом функциональными помоему глупо, если прилепить базу так ещё и нагрузочные тесты можно замутить, плохо лишь одно что надо будет хелперы писать чтоб подготовить состояние для самого теста, но опять же это заставляет думать о проблеме в целом, а не только независимый кусочек, если проэкт огромный то тогда ничё не поделаешь и надо модульно тестировать, но всё равно моков поминимуму и только для совсем внешних сервисов которые нельзя из тестов использовать
у меня такой подход отлично работает разве что уи не тестируется, да и то только потому что автоматизаторы сами должны были под это тесты написать, получается что не надо кнопки тыкать, а писать тест на требуемую ситуацию и под этот тест уже писать код, думать почти не надо как и чего сделать в коде, а ещё и всякие рантайм ошибки сразу вылезают связаные с байндингом и тому подобным, а значит нет человеческих ошибок типа забыл чегото там доконфить, которая вылезет только у тестеров
проверяют они столько же
Главная ошибка
в чём ошибка то?
В том, что функциональные тесты не проверяют работу приложения полностью.
Юнит-тестирование, на то и «Юнит». Чтобы отдельно проверить логически завершённый сегмент всевозможными данными, пройти по всем вилкам условий, выкинуть и отловить все Exception-ы.
Только после юнит-тестирования имеет смысл делать функциональные (как работает весь конвейер).
PS. Если юниттесты долгие, советую использовать заглушки модулей которые пытается вызвать тестируемая часть. Если ваш ЯП поддерживает monkey patching из коробки то задача упрощается до безобразия.
PPS. Если код плохо поддаётся тестированию — то код плохо написан
даже если покрывают 100%
Юнит-тестирование, на то и «Юнит». Чтобы отдельно проверить логически завершённый сегмент всевозможными данными, пройти по всем вилкам условий, выкинуть и отловить все Exception-ы.
Только после юнит-тестирования имеет смысл делать функциональные (как работает весь конвейер).
PS. Если юниттесты долгие, советую использовать заглушки модулей которые пытается вызвать тестируемая часть. Если ваш ЯП поддерживает monkey patching из коробки то задача упрощается до безобразия.
PPS. Если код плохо поддаётся тестированию — то код плохо написан
так, а где обьяснение? это всё и функциональными делается, валидаторы и места где 100500 вариантов естественно проще юнит тестами, но не обязательно всё зависит от сложности написания и скорости их работы, ведь важно в конце концов как всё вместе работает, и функциональные сложно писать и бегут долго в огромных сложных проэктах, там начальное состояние сложно создать, например софт который считал накопительную пенсию из данных за 30 лет, но даже тут только первый раз было сложно потому что данных дофига надо создать, работало бы быстрее юнит тесты вообще не писались бы
так, а где обьяснение?
Объяснение, прошу прощения, чего?
Того что функциональные не дают 100% покрытия? Так я объяснил, конвейер снижает вариативность поступающих данных (часть мутирует, часть валидируется). Функциональные тесты не выбрасывают половину Exception-ов глуша и обрабатывая их выше (в лучшем случае).
Юнит тесты сразу и точно показывают где что-то сломалось…
Есть у нас 100 модулей, каждый из которых прибавляет ко входящему параметру 1. Модули объединены в один конвейер. Покрываются одним функциональным тестом.
Правим 1 модуль теперь он добавляет 2 к параметру. Тест упал. В каком модуле произошла ошибка?
Ладно, это просто. Нашли в гите, поправили.
Два разработчика поправили по модулю. один теперь добавляет 0, второй добавляет 2. Ошибки компенсировали друг-друга. Тест пройден. Но приложение содержит ошибку. И когда эта мина подорвётся?
Во второй части своего комментария вы описываете необходимость функционального тестирования. С этим я не спорил
вот тут как раз таки и есть проблема избыточности, юнит тестом можно передать всякие невалидные данные которые никогда не дойдут то этого метода и из 10 строчек можно превратить всё в 100 строчек, а это вовсе не нужно, всю работу уже сделали другие модули
поиск модуля где всё сломалось вот тут наверно согласен, не надо дебажить, а можно сразу посмотреть в каком методе сломалось, но это если не использовать модульность и тдд, мы же не лезем в 10 методов сразу, а после того как что-то поменяли запустили тесты, и если что-то сломалось то это связано с последними изменениями, так что это больше похоже на тот случай когда тестов много и их все не запустить и поэтому есть найтли билд который сломался и чтоб не дебажить весь процесс нужны юнит тесты
последнее замечание не совсем валидно если код даёт в конце правильный результат и покрыт на 100% то и не важно что они компенсируют друг друга и всегда дадут нужный результат то что один модуль доделывает работу другого не критично(от перемены мест слагаемых сумма не меняется), ну по крайней мере до тех пор пока в этом коде ничего не меняется, а как будет меняться то и ошибка вылезет и будет исправлена
вобщем я понял вашу мысль и я не являюсь ярым противником юнит тестов их нужно писать где по другому сложнее так как они сократят время разработки, но нельзя забывать что чем больше тестов тем больше времени на их поддержку, и можно потерять всё сьэкономленное время на их переписывание и рефакторинг, был я в таких проэктах где основной упор был на юнит тесты (тысячи тестов) и в таких где на функциональные(несколько сотен) и с функциональными проект был менее проблемным, там где больше юнит тестов было получалось что всё покрыто и вроде должно работать, а всё вместе иногда не работало как надо
поиск модуля где всё сломалось вот тут наверно согласен, не надо дебажить, а можно сразу посмотреть в каком методе сломалось, но это если не использовать модульность и тдд, мы же не лезем в 10 методов сразу, а после того как что-то поменяли запустили тесты, и если что-то сломалось то это связано с последними изменениями, так что это больше похоже на тот случай когда тестов много и их все не запустить и поэтому есть найтли билд который сломался и чтоб не дебажить весь процесс нужны юнит тесты
последнее замечание не совсем валидно если код даёт в конце правильный результат и покрыт на 100% то и не важно что они компенсируют друг друга и всегда дадут нужный результат то что один модуль доделывает работу другого не критично(от перемены мест слагаемых сумма не меняется), ну по крайней мере до тех пор пока в этом коде ничего не меняется, а как будет меняться то и ошибка вылезет и будет исправлена
вобщем я понял вашу мысль и я не являюсь ярым противником юнит тестов их нужно писать где по другому сложнее так как они сократят время разработки, но нельзя забывать что чем больше тестов тем больше времени на их поддержку, и можно потерять всё сьэкономленное время на их переписывание и рефакторинг, был я в таких проэктах где основной упор был на юнит тесты (тысячи тестов) и в таких где на функциональные(несколько сотен) и с функциональными проект был менее проблемным, там где больше юнит тестов было получалось что всё покрыто и вроде должно работать, а всё вместе иногда не работало как надо
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Концепции автоматического тестирования