Comments 96
На мой взгляд модульные тесты надо писать просто потому, что это не так уж сложно, а тестировать свой модуль вы будете так или иначе. Так почему бы не оставить тесты как наследие?
Разрабатывайте свой модуль через тестирование (ну или почти так) и вы не будете париться о затраченном времени, так как оно и так было бы затрачено на какой-нибудь тестовый файл. При рефакторинге же вы как раз сэкономите время, так как будете знать где именно надо править код, чтобы программа вновь работала.
Вы пишите, что программисты не тщательно тестируют код — это как раз проблемы программистов, тестировщики могут быть такими же (ибо почему нет?). Однако, это не отменяет необходимость приемочных тестов. Просто тестировать по идее надокаждый пук всё. Я глубоко убежден, что только так можно построить действительно хорошее приложение.
Разрабатывайте свой модуль через тестирование (ну или почти так) и вы не будете париться о затраченном времени, так как оно и так было бы затрачено на какой-нибудь тестовый файл. При рефакторинге же вы как раз сэкономите время, так как будете знать где именно надо править код, чтобы программа вновь работала.
Вы пишите, что программисты не тщательно тестируют код — это как раз проблемы программистов, тестировщики могут быть такими же (ибо почему нет?). Однако, это не отменяет необходимость приемочных тестов. Просто тестировать по идее надо
Скажем так — не надо писать приемочные тесты вместо модульных — надо вместе.
К сожалению есть несколько проблем
>>Вы пишите, что программисты не тщательно тестируют код — это как раз проблемы программистов, тестировщики могут быть такими же (ибо почему нет?).
Абсолютно разная мотивация — я уже писал почему.
А во вторых, далеко не всё что пишеться, действительно нужно. Особенно в стартапах/прототипах. И очень часто вместо рефакторинга часть кода просто переписываеться с нуля. Приемочные тесты частично остаются, а вот юниты — под снос.
Собственно я и написал итогово — писать или не писать модульные тесты — решение разработчиков — им они нужны. А вот приёмочные — это правило.
>>Вы пишите, что программисты не тщательно тестируют код — это как раз проблемы программистов, тестировщики могут быть такими же (ибо почему нет?).
Абсолютно разная мотивация — я уже писал почему.
А во вторых, далеко не всё что пишеться, действительно нужно. Особенно в стартапах/прототипах. И очень часто вместо рефакторинга часть кода просто переписываеться с нуля. Приемочные тесты частично остаются, а вот юниты — под снос.
Собственно я и написал итогово — писать или не писать модульные тесты — решение разработчиков — им они нужны. А вот приёмочные — это правило.
Если промотивацию, то читайте, если вдруг не читали. Я с вами не согласен. Если мотивации у программиста нет, то и делать ему нечего в этом проекте — так как будет не самый лучший код — так как ему просто пофиг.
Тестировщики тоже в первую очередь должны тестировать нормальное поведение программы, чтобы пользователи смогли ей пользоваться. И только потом тестировать — «а что будет, если я впихну очень длинную строку в input поле». Программист же должен заботиться о тестах на пустое значение и на заполненное в нормальной форме (если это не что-то вроде регулярного значения).
Тестировщики тоже в первую очередь должны тестировать нормальное поведение программы, чтобы пользователи смогли ей пользоваться. И только потом тестировать — «а что будет, если я впихну очень длинную строку в input поле». Программист же должен заботиться о тестах на пустое значение и на заполненное в нормальной форме (если это не что-то вроде регулярного значения).
«никогда не угадаешь, что может ввести пользователь, которому дали поля ввода и клавиатуру» — не помню чьё, но таки правда. У тестеров есть деление на приоритеты ошибок, так что редко случаемые варианты использования идут более низким приоритетом.
Насчёт мотивации — я видел огромное колличество влюблённых в свою работу разработчиков, которые готовы сидеть сутками (мой рекорд -26 часов кодинга) лишь бы продукт вышел в срок. Но хороший тестер найдёт ошибки в их, покрытых юнит тестами кодах. не потому что мотивации нет, просто она другая.
Насчёт мотивации — я видел огромное колличество влюблённых в свою работу разработчиков, которые готовы сидеть сутками (мой рекорд -26 часов кодинга) лишь бы продукт вышел в срок. Но хороший тестер найдёт ошибки в их, покрытых юнит тестами кодах. не потому что мотивации нет, просто она другая.
Мы не роботы — все ошибаются. Я уверен, что даже самый лучший тестер тоже может пропустить баг. И что теперь?
Вероятность меньше, вот и всё. Это как разница между военным и гражданским ПО — везде есть ошибки, но очевидно что в военной технике их меньше (потому что подходы к тестированию другие).
Кто Вам сказал?
Просто опыт. Как правило тестер находит больше ошибок чем программист (особенно программист в собственно написанном функционале)
Тестировать надо всё. И надо ровняться на одних из лучших, а там тестируют всё и все.
Где-то я читал, по статистике у NASA 1 ошибка на 1 млн. строк кода. И соглашусь с sectus — кто вам сказал, что вероятность ошибки тестера меньше?
К сожалению, не смог быстро найти какими методологиями пользуются в NASA. Но почему то я считаю, что тестировщиков они используют.
А я и не говорю вам, что они не нужны. Я говорю о том, что не надо снижать значимость модульных тестов.
Я и не снижаю. Как правильно заметил DmitryKoterov юнит тесты это инструмент. И их значимость зависит от того, как вы их используете. Для меня Netbeans весьма значим, а мой товарищ кодит в Notepad++ и говорит что лучше ничего нет ;)
Я лишь хочу сказать, что модульное тестирование не гарантирует работоспособность продукта
Я лишь хочу сказать, что модульное тестирование не гарантирует работоспособность продукта
Ну, если на то пошло — то ничего не гарантирует вам работоспособность продукта на 100% и на один тестер в здравом уме на даст вам эту гарантию. Так как навряд ли вы тестируете — как, например, поведут себя демоны вашего приложения, если при питание сервера просто выключить, а потом включить. Кроме того я вам скажу, что навряд ли много разработчиков в принципе заботятся о реализации функционала восстановления после падения системы, а надо бы.
>>Так как навряд ли вы тестируете — как, например, поведут себя демоны вашего приложения, если при питание сервера просто выключить, а потом включить
тестируем. Специально даже кнопки делали, на тестовом окружении — вырубить сервер, вырубить СУБД, вырубить кеш.
Но это мелочи. Попытаюсь ещё раз донести мысль — с тестерами багов проходит меньше (чем без них :)).
тестируем. Специально даже кнопки делали, на тестовом окружении — вырубить сервер, вырубить СУБД, вырубить кеш.
Но это мелочи. Попытаюсь ещё раз донести мысль — с тестерами багов проходит меньше (чем без них :)).
Кстати, можно ли сказать, что Вы несогласны с основным тезисом статьи Тестирование — это не поиск ошибок!?
С заголовком — нет, не согласен :) Тестирование — это поиск ошибок в зависимости от их приоритета и вероятности появления — а именно это хотел рассказать автор в статье по ссылке, и с этим я согласен.
Тут я не согласен. Тестирование — это не поиск ошибки. Тестирование — это способ удостоверится, что всё работает так как задумал… автор, разработчик, писатель ТЗ, заказчик и т.д…
И, если я загляну в душу тестировщика так же легко как Вы заглянули в душу программиста, то увижу, что тестировщик, которому поставлена задача искать ошибки, будет искать ошибки, а не разбираться со сложными алгоритмами, которые были заложены в приложение.
И, если я загляну в душу тестировщика так же легко как Вы заглянули в душу программиста, то увижу, что тестировщик, которому поставлена задача искать ошибки, будет искать ошибки, а не разбираться со сложными алгоритмами, которые были заложены в приложение.
Абсолютно согласен.
Иногда, особенно после тренингов, тестировщики увлекаются поиском каверзных значений при которых не работает функционал в ущерб проверки success сценариев. Радуются как дети если нашли что. А при этом основной функционал не работает по итогам.
Не согласен с выводом что юнит тесты не обязательны. И видимо другие виды что пишет разработчик. Предположу что автор не сталкивался с большими и сложными проектами где очень много кода и система не находится в состоянии покоя — не сделал и сдал заказчику а постоянно эволюционирует. Вот где изменения без тестов рушат все и сразу.
Иногда, особенно после тренингов, тестировщики увлекаются поиском каверзных значений при которых не работает функционал в ущерб проверки success сценариев. Радуются как дети если нашли что. А при этом основной функционал не работает по итогам.
Не согласен с выводом что юнит тесты не обязательны. И видимо другие виды что пишет разработчик. Предположу что автор не сталкивался с большими и сложными проектами где очень много кода и система не находится в состоянии покоя — не сделал и сдал заказчику а постоянно эволюционирует. Вот где изменения без тестов рушат все и сразу.
Как можно говорить о поиске ошибок в случае TDD/BDD? Ещё кода нет, чтобы ошибки в нём искать.
Автоматическое тестирование — это, прежде всего, фиксация поведения, декларативное описание того, что код должен делать.
Автоматическое тестирование — это, прежде всего, фиксация поведения, декларативное описание того, что код должен делать.
Юнит-тусты (модульные тесты) — инструмент ведения разработки в стиле TDD или полу-TDD (такой же, как текстовый редактор, клавиатура и т.д.). Без них в ряде случаев написать код если и не невозможно, то на несколько порядков сложнее, чем с ними (яму можно выкопать и инструментом-ложкой, но удобнее применять инструмент-лопату). Также это инструмент рефакторинга.
Функциональные тесты — инструмент для тестировщика, когда его достает раз за разом производить одни и те же действия. В какой-то степени также уменьшают паранойю разработчика от того, что сделанное изменение сломает систему в неожиданном месте.
Я бы еще выделил дымовые тесты (назовем их так, хотя я не вполне уверен), что-то промежуточное между 1 и 2. Они достаточно низкоуровневые для того, чтобы их мог писать только разработчик, однако основная их цель — снизить паранойю. Типичный пример — регрессионные тесты phpt. Крайне удобны тем, что их можно штамповать десятками в течение часа и тем, что они очень читабельны; неудобны же тем, что если они ломаются, нужен цикл отладки, чтобы понять, из-за чего же. Идеально подходят для библиотек, стабильность которых и гарантия неповторяемости прошлых исправленных багов очень важны.
Функциональные тесты — инструмент для тестировщика, когда его достает раз за разом производить одни и те же действия. В какой-то степени также уменьшают паранойю разработчика от того, что сделанное изменение сломает систему в неожиданном месте.
Я бы еще выделил дымовые тесты (назовем их так, хотя я не вполне уверен), что-то промежуточное между 1 и 2. Они достаточно низкоуровневые для того, чтобы их мог писать только разработчик, однако основная их цель — снизить паранойю. Типичный пример — регрессионные тесты phpt. Крайне удобны тем, что их можно штамповать десятками в течение часа и тем, что они очень читабельны; неудобны же тем, что если они ломаются, нужен цикл отладки, чтобы понять, из-за чего же. Идеально подходят для библиотек, стабильность которых и гарантия неповторяемости прошлых исправленных багов очень важны.
Мне кажется что ваша проблема в том, что вы тестируете без спецификации, что вообще говоря, делать бессмысленно.
Если программист может вот так вот взять и поменять checkInt() на проверку чисел со знаком когда до этого она проверяла только беззнаковые и его это ни капельки не смутило и не нужно было менять спецификацию (да, пусть это будет одно предложение в документационном комментарии перед функцией) — то нужно исправлять программистов, а не занижать значимость юнит-тестов.
Если программист может вот так вот взять и поменять checkInt() на проверку чисел со знаком когда до этого она проверяла только беззнаковые и его это ни капельки не смутило и не нужно было менять спецификацию (да, пусть это будет одно предложение в документационном комментарии перед функцией) — то нужно исправлять программистов, а не занижать значимость юнит-тестов.
К сожалению это реалии — Я ещё НИ РАЗУ не видел проект, где ВСЕ функции покрыты спецификациями/документацией. Максимум — короткий комментарий. Спецификации могут существовать на момент написания кода, но к моменту рефакторинга бывают напрочь утеряны.
Короткого комментария со словом «unsigned» было бы достаточно. А ещё лучше вынести это слово в название функции.
безусловно, checkUnsignedInt32 значительно лучше и понятнее. Но это лишь пример. Обычно, к сожалению, функции намного сложнее, и выписать что они должны делать в название доходчиво — не получается. Опять таки, на моей практике было как минимум 5 случаев, когда комментарий/название функции не соответствовали тому, что она делала(нет, не я их так назвал :) ).
Как по-вашему, какова задача юнит-тестов?
Простой пример: допустим у нас есть функция checkInt(a){return /^[0-9]+$/.test(a)}. При этом в юнит-тесте нет проверки на отрицательное число. Что это значит? А то, что если некий разработчик модифицирует данную функцию как
checkInt(a){return /^-?[0-9]+$/.test(a)}, то юнит-тест будет проходить как ни в чём не бывало. А вот функционал будет повреждён.
Эээ? Какая же функциональность будет повреждена? Те числа, которые ранее проходили по тесту, будут продолжать проходить. Если не было проверки на то, что отрицательные числа не должны проходить, значит, это не было важно, а значит, функциональность не затронута.
А после того, как ошибка будет найдена и исправлена (функция вернётся к своему изначальному состоянию), отвалится часть функционала в другом месте. При неизменно удачном прохождении юнит-тестов.
Тоже не верно, потому что первое правило при изменении — напиши новый юнит-тест, который сейчас не проходит, а после изменения будет проходить. Вот он и должен будет отвалиться при регрессии.
>> Если не было проверки на то, что отрицательные числа не должны проходить, значит, это не было важно, а значит, функциональность не затронута.
А было ли это не важно? Чтоб ответить на этот вопрос нужно либо искать автора, либо разбераться где функция используется (все места).
>>Тоже не верно, потому что первое правило при изменении — напиши новый юнит-тест, который сейчас не проходит, а после изменения будет проходить. Вот он и должен будет отвалиться при регрессии.
Верно, именно этот юнит-тест матерящийся автор и поменяет обратно, после исправления функции назад :) А ваш функционал всё равно отвалится. Нет, конечно, в идиальном мире, всё будет хорошо.
А было ли это не важно? Чтоб ответить на этот вопрос нужно либо искать автора, либо разбераться где функция используется (все места).
>>Тоже не верно, потому что первое правило при изменении — напиши новый юнит-тест, который сейчас не проходит, а после изменения будет проходить. Вот он и должен будет отвалиться при регрессии.
Верно, именно этот юнит-тест матерящийся автор и поменяет обратно, после исправления функции назад :) А ваш функционал всё равно отвалится. Нет, конечно, в идиальном мире, всё будет хорошо.
А было ли это не важно?
Не было теста — не было важно.
Верно, именно этот юнит-тест матерящийся автор и поменяет обратно, после исправления функции назад
А вот так делать банально нельзя. Если в тесте написано, что «при отрицательных значения должно возвращать true», то он не просто так написан. Дальше нужно поднимать историю кода и смотреть, зачем так написано.
И я вас уверяю, вид тестов (модульные/интеграционные/функциональные) тут не при чем, эта проблема совершенно одинакова в любом из них.
Как правило, это разработчик, и его цель — покрытие кода юнит-тестами. А это значит, что скорее всего, юнит-тест будет весьма не полным
С тем же успехом можно написать, что цель разработчика — сделать бажный продукт, т.к. я не видел еще не разу продукта без багов. Тут многое зависит от менеджера и опытности программиста, а говорить «как правило» — несколько надуманно. Как правило, юнит тесты вообще не пишутся.
В общем, культура TDD — это не написание тестов для галочки, а написание всевозможных сценариев для проверки. И автор забыл упомянуть такой подход: нашли баг — напиши юнит тест, чтобы этот баг не всплыл обратно. После этого юнит тесты заиграют новыми красками.
>>Как правило, юнит тесты вообще не пишутся.
Блин, привычка из скайпа, нажимать ctrl+enter чтоб перейти на следующую строку
По теме:
Да, как правило юнит тестов вообще нет. И применяеться не TDD, а покрытие кода после написания. И именно о нём я писал (я же не написал сравнение подхода TDD с функциональными тестами). И в этой ситуации модульные тесты часто пишуться для галочки — есть покрытие — есть, ну и фиг с ним. И это ужасно. не потому что программист плохой, или хочет сделать бажный код, что Вы, НЕТ! Просто он воспринимает модульное тестирование как новую блаж начальства.
По теме:
Да, как правило юнит тестов вообще нет. И применяеться не TDD, а покрытие кода после написания. И именно о нём я писал (я же не написал сравнение подхода TDD с функциональными тестами). И в этой ситуации модульные тесты часто пишуться для галочки — есть покрытие — есть, ну и фиг с ним. И это ужасно. не потому что программист плохой, или хочет сделать бажный код, что Вы, НЕТ! Просто он воспринимает модульное тестирование как новую блаж начальства.
> модульное тестирование как новую блаж начальства
Разве тесты в этом виноваты? Или, я начинаю догадываться, цель статьи — выяснить какие тесты более полезны при условии что тесты делаются для галочки?
Разве тесты в этом виноваты? Или, я начинаю догадываться, цель статьи — выяснить какие тесты более полезны при условии что тесты делаются для галочки?
Попробуйте прийти в коллектив, который НЕ покрывал продукт тестами, и попытаться ввести в разработку модульные или приёмочные тесты.
Я думаю после такой практики, Вы со мной согласитесь. Или напишите ещё одну статью, которую я с огромным удовольствием прочитаю
Я думаю после такой практики, Вы со мной согласитесь. Или напишите ещё одну статью, которую я с огромным удовольствием прочитаю
Зачем писать статью если есть замечательная книга — Working effectively with legacy code. Хочу обратить ваше внимание на определение понятия legacy code, которое там даётся.
Ну вот мы ввели модульные и интеграционные тесты существенно позже десяти тысяч строк кода. В системе, где до этого никаких тестов не было. И что?
И этим мы зафиксировали текущее поведение системы. Правильное, неправильное — всё вместе.
Ну вообще нет, потому что «ввели» не значит «покрыли все целиком». Но идея была в том, чтобы сначала зафиксировать легаси-поведение (не важно, какое, важно, что остальная система работает именно так), а потом его рефакторить. Собственно, как у Физерса и полагается.
Я к тому, что ничего невозможного.
Я к тому, что ничего невозможного.
>>Это первая ошибка. Нельзя покрывать код тестами после написания (не важно, какими).
Вы сами себе противоречите, или я Вас просто не понимаю?
Вы сами себе противоречите, или я Вас просто не понимаю?
И применяеться не TDD, а покрытие кода после написания
Это первая ошибка. Нельзя покрывать код тестами после написания (не важно, какими).
Просто он воспринимает модульное тестирование как новую блаж начальства.
Это вторая ошибка.
И обе ошибки — в методологии.
Когда вы приходите на частично готовый проект, то нужно работать, а не рассуждать какая методология была верной. И переписать с нуля проект вам никто не даст. Я говорю именно о таких условиях.
Вот имено это и приводит к проектам, которые остаются в состоянии «частично готовый» навсегда. Никто не мешает внедрять юнит-тесты в середине проекта, просто нужно уметь это делать.
Собственно, то, что о чем вы пишете — это совершенно академический пример, прекрасно описанный в книжке xUnit Test Patterns. Вы прошли ровно по всем граблям: пытаетесь применить модульное тестирование в середине проекта, пытаетесь это сделать для уже написанного кода и при этом не имеете опыта работы с модульными тестами. Собственно, результат тоже описан в книге — недовольство юнит-тестами как подходом и отказ от них.
Собственно, то, что о чем вы пишете — это совершенно академический пример, прекрасно описанный в книжке xUnit Test Patterns. Вы прошли ровно по всем граблям: пытаетесь применить модульное тестирование в середине проекта, пытаетесь это сделать для уже написанного кода и при этом не имеете опыта работы с модульными тестами. Собственно, результат тоже описан в книге — недовольство юнит-тестами как подходом и отказ от них.
Можно один вопрос: Почему Вы считаете, что я отказываюсь от модульных тестов?
Вот из этой фразы: «Юнит-тесты — желательно, но зависит от настроения разработчиков». Ну и весь пассаж про «недостатки» модульных тестов.
Всё в этом мире имеет недостатки, неправда ли?
Я полностью согласен с фразой «тестировать всё что только можно». Но если у вас очень ограничены ресурсы, зачастую приходиться выбирать. Вся идея статьи лишь в том, что юнит тесты не заменят приёмочных, и если при комите изменний полагаться только на результаты юнит-тестов то велик шанс что-нибудь угробить.
Я полностью согласен с фразой «тестировать всё что только можно». Но если у вас очень ограничены ресурсы, зачастую приходиться выбирать. Вся идея статьи лишь в том, что юнит тесты не заменят приёмочных, и если при комите изменний полагаться только на результаты юнит-тестов то велик шанс что-нибудь угробить.
А приемочные тесты, по вашему, могут заменить модульные?
Если все приёмочные тесты после ваших изменений выполняются удачно, то — добавляйте свои изменения в репозиторий смело, если что — вините тестеров :)
А вот ошибку без модульных тестов искать будет много тяжелее, это да
А вот ошибку без модульных тестов искать будет много тяжелее, это да
Ага.
А вы гоняете все приемочные тесты по всей системе после каждого изменения?
А вы гоняете все приемочные тесты по всей системе после каждого изменения?
Лично я стараюсь прогнать после стягивания кода из репозитория (собственно это быстрейший способ убедиться что ничего никто не сломал). И перед тем как сам буду заливать значительные изменения.
Гхм…
Простите, не могли бы вы нам рассказать про размер системы и количество тестов?
Простите, не могли бы вы нам рассказать про размер системы и количество тестов?
По всей системе? И сколько часов это у вас занимает?
(ну и да, я что-то не понимаю, вы тестировщик или разработчик? если тестировщик, то почему вы «стягиваете» код? если разработчик, то почему вы гоняете функциональные тесты, которые в вашей системе ценностей пишет тестировщик?)
(ну и да, я что-то не понимаю, вы тестировщик или разработчик? если тестировщик, то почему вы «стягиваете» код? если разработчик, то почему вы гоняете функциональные тесты, которые в вашей системе ценностей пишет тестировщик?)
Разработчик. И мне не сложно попросить тестера прогнать приёмочные тесты для модуля (так уж пошло, что мой модуль довольно изолирован, и вносимый мной код повредить чужой не может, а вот наоборот — всегда пожалуста :) )
Честно говоря, моя б воля, ставил бы на ночь и всю прогонку, но из-за особенности организации работы, далеко не все приёмочные тесты проходят удачно (попросту — на них забивают, и «радуются» на релизах)
Прогонка всех тестов для модуля занимает минут 15.
Отвечая на коментарий выше, нет размер системы и количество тестов указать не могу :)
Честно говоря, моя б воля, ставил бы на ночь и всю прогонку, но из-за особенности организации работы, далеко не все приёмочные тесты проходят удачно (попросту — на них забивают, и «радуются» на релизах)
Прогонка всех тестов для модуля занимает минут 15.
Отвечая на коментарий выше, нет размер системы и количество тестов указать не могу :)
И мне не сложно попросить тестера прогнать приёмочные тесты для модуля
То есть — не для всей системы. Это означает, что тот факт, что остальная система не упала, вы ничем гарантировать не можете (только утверждением, что вносимый вами код ничего не ломает, но кто же разработчику верит?).
из-за особенности организации работы, далеко не все приёмочные тесты проходят удачно
И вы после этого говорите, что приемочные тесты чем-то лучше модульных?
безусловно. Именно поэтому. Именно потому что работоспособность небольшого количества приёмочных тестов способно гарантировать работоспособность моего модуля. Как результат — ни единого фейла на релизах.
Я пишу исходя из реальных условий. Далеко не идиальных. И если б я мог я их изменил. Но в данных условиях, единственная надежда на приёмочные тесты.
Я пишу исходя из реальных условий. Далеко не идиальных. И если б я мог я их изменил. Но в данных условиях, единственная надежда на приёмочные тесты.
Именно потому что работоспособность небольшого количества приёмочных тестов способно гарантировать работоспособность моего модуля.
Раз уж все сравнения идут только на примере вашего модуля, получается, что именно вы, а не абстрактный разработчик, не можете так написать юнит-тесты, чтобы гарантировать работоспособность вашего модуля?
единственная надежда на приёмочные тесты.
На те самые, на которые забивают.
Раз уж все сравнения идут только на примере вашего модуля, получается, что именно вы, а не абстрактный разработчик, не можете так написать юнит-тесты, чтобы гарантировать работоспособность вашего модуля?
Юнит тесты тестируют работу модуля, а не взаимодействие системы, верно? А кому какое дело, что мой модуль должен работать верно, если он не работает в конкретном окружении? :)
На те самые, на которые забивают.
Вы либо не внимательно читаете, либо стараетесь всеми силами доказать свою правоту. И в том и другом случае дискуссию нет смысла продолжать
А кому какое дело, что мой модуль должен работать верно, если он не работает в конкретном окружении? :)
Если модуль работает верно, а ошибка в окружении — ее кто правит?
Зависит от обстоятельств. Иногда проще поправить самому, чем искать виноватого(Или ждать от него фиксов). Иногда (когда мы говорим о очень важных участках кода) лучше найти автора.
А как у вас?
А как у вас?
Если «поправить самому», то вы уже вылезли за пределы своего модуля. А это возвращает нас к вопросу «кто тестируют всю систему на регрессию и как часто». А если «лучше найти автора», то приемочные тесты на ваш код продолжают не работать, и пинать ответственность можно бесконечно.
А у нас shared code ownership, но в границах личной компетенции.
А как у вас?
А у нас shared code ownership, но в границах личной компетенции.
А это возвращает нас к вопросу «кто тестируют всю систему на регрессию и как часто».
Если не можешь изменить мир — измени себя. Если невозможно, по обьективным причинам обеспечить работоспособность всей системы, я всё же могу обеспечить работоспособность подответственного участка работы.
Проблема в том, что обобщения о том, какие тесты выгоднее, сделанные на основе одного модуля, на систему распространяются плохо.
Особенно в вопросе, что выгоднее — покрыть некий (широко используемый) кусочек функциональности юнит-тестом или функциональными тестами.
Особенно в вопросе, что выгоднее — покрыть некий (широко используемый) кусочек функциональности юнит-тестом или функциональными тестами.
маленький и широко используемый — ТОЛЬКО юнит тест (т.к. он будет документацией, как можно использовать, а как — нет) :) А вот использование этого маленького кусочка в рамках вашего модуля — уже лучше функциональным. А как Вы считаете?
маленький и широко используемый — ТОЛЬКО юнит тест
Правда? Тогда перечитайте свой собственный пост, начиная с абзаца «Самое главное — даже успешное прохождение всех юнит-тестов не гарантирует правильной работы продукта: ведь одна и та же функция может быть использована в различных частях системы, в то время как юнит-тест писался для неё с оглядкой лишь на один вариант использования.»
Теперь уже вы себе противоречите, потому что ваша checkInt — типичный пример маленького широко используемого куска.
Нет, не противоречие. повсеместно используемые библиотеки должны быть покрыты юнит-тестами, но это не гарантирует их правильное применение. А вот правильное применение, и вообще правильность и работоспособность написанного функционала гарантируют приёмочные тесты. Что я и написал в комментарии.
А откуда возьмутся полные юнит-тесты на повсеместно используемую библиотеку, если в вашем примере checkInt ими не была покрыта?
Очевидно, что полное покрытие — это из той же области что и код без багов. И я о полном покрытии не говорил
Я, знаете ли, уже запутался.
Давайте на конкретном примере. Вот есть тупой валидационный метод checkInt, который проверяет, что переданная в него строка — число, а не какая-нибуть НГХ. Этот метод используется во всем проекте.
Каким образом (с разумными трудозатратами) гарантировать, что изменение этого метода не нарушило поведение системы?
Давайте на конкретном примере. Вот есть тупой валидационный метод checkInt, который проверяет, что переданная в него строка — число, а не какая-нибуть НГХ. Этот метод используется во всем проекте.
Каким образом (с разумными трудозатратами) гарантировать, что изменение этого метода не нарушило поведение системы?
Только приёмочные тесты в местах использования. Которые не могут быть изменены при изменении кода этой функции
То есть при каждом изменении нужно прогнать все приемочные тесты по всей системе.
Вы, простите, затраты на это считали?
Вы, простите, затраты на это считали?
Ваш вариант?
При добавлении каждого места использования (для унаследованных систем — при обнаружении бага или доработки) пишется два юнит-теста. Первый — на то, что потребитель вызывает метод и реагирует на его результат заданным образом (тест на встраивание). Второй — что метод корректно себя ведет при том использовании, которое нужно этому потребителю. Поскольку тесты из второй группы очень быстро начнут повторяться, скоро их не надо будет писать.
Кстати, вы сами-то кто по жизни? Руководитель, разработчик, тестер, аналитик, подчеркнуть нужное?
Вы выдаете очень категоричные суждения, слабо подкрепленные аргументацией, и мне хотелось бы знать, чьи суждения я читаю.
Спасибо.
Вы выдаете очень категоричные суждения, слабо подкрепленные аргументацией, и мне хотелось бы знать, чьи суждения я читаю.
Спасибо.
«К тому же, существует огромное число функций, проверить которые модульным тестированием невозможно, либо очень сложно (это функции, поведение которых зависит от состояния системы в целом). „
You do it wrong.
Такие функции очень сильно воняют, и в первую очередь — кандидаты на рефакторинг.
У вас проблема с декомпозицией.
Модульное тестирование — оно потому и модульное, что тестирует изолированный модуль, а не состояние всей системы.
You do it wrong.
Такие функции очень сильно воняют, и в первую очередь — кандидаты на рефакторинг.
У вас проблема с декомпозицией.
Модульное тестирование — оно потому и модульное, что тестирует изолированный модуль, а не состояние всей системы.
Плохая задача для тестеров: «найти ошибку». Хорошая — протестировать систему, т.е. предоставить наиболее полную информацию о системе. В которой указаны и ошибки. Извините, но мне как тестеру глаза сильно режет.
Имхо, писать и модульные, и функциональные тесты обязанность разработчика. Для тестировшиков есть приемочные, нагрузочные и т. п. И уж точно модульные и функциональные пишутся не для выявления ошибок, а для закрепления спецификаций (пускай и выраженных только самими тестами). Если они пишутся на существующий код, то должны сначала пройти, даже если фиксируют явно бажное поведение, и лишь потом изменяться для правильного поведения.
А противостояние модульных и функциональных нелепо. Они решают разные задачи, но комбинируя их можно уменьшить число и/или сложность и тех, и других.
А противостояние модульных и функциональных нелепо. Они решают разные задачи, но комбинируя их можно уменьшить число и/или сложность и тех, и других.
>Функциональные тесты — обязательно
>Юнит-тесты — желательно, но зависит от настроения разработчиков
Я бы в зависимость от прям вот настроения не ставил. Если ждать вдохновения — то никаких юнит тестов не будет.
И тогда легко и быстро скатиться к ситуации, когда
— 30% времени билд тупо не собирается или собирается, но не проходит базовые проверки
— 30% времени тестировщики тратят время на описание «простых и очевидных» багов в трекере, продираются через эти баги, обходят их как-то
— 10% времени тестировщики объясняют, почему тестирование движется так медленно
— 5% времени уходит на перепланирование в связи с поплывшими сроками
— 25% времени тратится на тестирование (включая сюда анализ, тест-дизайн, настройку окружения, репорты и т.д.)
Утрировано, но, думаю, идея понятна. Если программист снимает с себя ответственность за качество (проверять — это ж работа тестировщика!), то никакой отдел тестирования уже ничего не спасет. Разве что тестировщики начнут чинить процессы разработки и внедрять полезные практики, вместо того чтоб грызть кактус…
>Юнит-тесты — желательно, но зависит от настроения разработчиков
Я бы в зависимость от прям вот настроения не ставил. Если ждать вдохновения — то никаких юнит тестов не будет.
И тогда легко и быстро скатиться к ситуации, когда
— 30% времени билд тупо не собирается или собирается, но не проходит базовые проверки
— 30% времени тестировщики тратят время на описание «простых и очевидных» багов в трекере, продираются через эти баги, обходят их как-то
— 10% времени тестировщики объясняют, почему тестирование движется так медленно
— 5% времени уходит на перепланирование в связи с поплывшими сроками
— 25% времени тратится на тестирование (включая сюда анализ, тест-дизайн, настройку окружения, репорты и т.д.)
Утрировано, но, думаю, идея понятна. Если программист снимает с себя ответственность за качество (проверять — это ж работа тестировщика!), то никакой отдел тестирования уже ничего не спасет. Разве что тестировщики начнут чинить процессы разработки и внедрять полезные практики, вместо того чтоб грызть кактус…
Если все приёмочные тесты проходят удачно, то чего не хватает тестерам чтоб работать дальше?
Приемочные тесты — во-первых, это ну совсем базовые вещи (по кр. мере у нас так). Это никак не обещает, что при шаге в сторону все продолжит работать. Всегда приходится искать баланс между «больше проверок» и «быстрее». Достаточно скоро мы попадаем в ситуацию, когда билды собираются много чаще, чем успевает отработать приемка. И тогда начинаются вопросы: а зачем вы используете такой старый билд?
Кроме того — приемочные тесты это регрессия, а тестировать мы стремимся новые фичи, нет? Они не покрыты приемочными тестами по определению, и запросто могут не работать. Далее по тексту — баги, обходные маневры, время потраченное в багтрекер, тестровщик глядящий на дождь за окном.
Кроме того — приемочные тесты это регрессия, а тестировать мы стремимся новые фичи, нет? Они не покрыты приемочными тестами по определению, и запросто могут не работать. Далее по тексту — баги, обходные маневры, время потраченное в багтрекер, тестровщик глядящий на дождь за окном.
хм, мы пошли другим путём. По сути все действия тестера записываються в приёмки. Которые мы можем для новых фич запускать отдельно (ну согласитесь, тяжело добавив поле сломать чтонибудь на другой странице). Более того, некоторые тесты пишутся даже с опережением функционала (да, частично вслепую). Таким образом, новые фичи покрываются автоматическими тестами очень быстро (буквально за пару часов после завершения работы над ними), после чего программист начинает править баги, до тех пор, покуда приёмочные тесты не будут выполнены.
Кроме того — приемочные тесты это регрессия, а тестировать мы стремимся новые фичи, нет? Они не покрыты приемочными тестами по определению
Вообще-то, в обратном порядке. Приемочный тест-кейс на фичу должен быть до ее появления (в идеале — включен в требования). Регрессионным он становится тогда, когда мы начинаем повторять эти тесты по уже принятым фичам (чтобы проверить, что они не сломались, т.е. мы не нарушили старые требования).
Я думаю мысль автора была в несколько другом. Важность модульного тестирования в некоторых методиках разработки очевидно. Однако его почему-то часто воспринимают как панацею, забывая о других вариантах тестирования. И тут я автора поддерживаю — сколько бы ни было у вас Unit-тестов и какое бы ни было покрытие кода, функционального тестирования это не заменит.
Функциональные тесты полностью определяют (по крайней мере должны) работоспособность продукта. И прежде всего нужны заказчику/руководителю разработки. Юнит тестирование прежде всего нужно самим разработчикам, для быстрого нахождения ошибок или проверки последствий рефакторинга. Поэтому приоритет должен стоять таким образом:
Функциональные тесты — обязательно
Юнит-тесты — желательно, но зависит от настроения разработчиков
заказчку нужны сроки, руководителю — бабло, а разработчику — писать код. поэтому в чистом виде, любые тесты зависят от настроения, т.к. напрямую не уперлись никому. их использование граничит с вопросами экологии или культуры. :)
мне кажется, что ваша приоритезация, вероятно, отражает текущую фазу разработки. когда, в моменте, доминирует проектирование «сверху-вниз», то появляются acceptance-тесты и тесты, порождаемые по дедукции в tdd, как на картинке. когда синтезируется решение «снизу-вверх» — юнит и интеграционные.
Sign up to leave a comment.
Юнит тесты Vs функциональные тесты — взгляд руководителя и разработчика