Добрый день! Это хорошие рассуждения. Полагаю, можно начать с того, что единственное что вы "должны" - это в контракте с работодателем или с заказчиком, а остальное решается между разрабами, и решается очень по разному.
Описанное вами есть сугубо "мокистский" (очень не люблю это слово) подход. Только заместо "интеграционных" тестов я предпочитаю что-нибудь, что заходило бы через эндпоинты или через event listener, а проверяло бы HTTP Response, сайд эффекты в базе, события, или прочие внешние проявления поведения кода. Это ещё иногда называется фуникциональными тестами, системными, E2E, зависит от команды.
То, что вы называете "не рыба и не мясо" - как раз юнит тестирование по Фаулеру и Хорикову. У них "юнит" это не единица кода, а единица бизнес требований. Если вы почитаете их труды, то они вполне детально объясняют, в чём видят пользу последнего, что я и обсуждаю.
Соответственно, возникает вопрос, что выбрать. Вы можете выбрать всё сразу, но это может быть черезчур. Хотя и такое бывает. Я предпочитаю искать компромисс.
Что касается практик внутри конкретного бизнеса, может доходить до крайнего. Например, весьма непринято погружаться в тестирование у некоторых консалтеров. Такие бизнесы могут ставить своей задачей выдать готовый прототип за 2-3 месяца и отдать его кому-либо на дальнейшее поддержание. Предложение "давайте лучше тестировать" тут могут встретить в штыки. Хотя, повторюсь, крайность.
Правильно понимаю, что у вас какой-то хардварный кейс? Не могу прокомментировать, потому что с таким не работал. Но был бы очень рад узнать подробности. ?
Интеграционные тесты - очень растяжимое понятие. Если мы говорим о тестах, которые покрывают всю систему целиком, то они не являются заменой unit тестам, тут я с вами согласен. Посыл был скорее в том, что для вас не всегда может быть доступен или возможен какой-то один тип тестирования. Такое может произойти из-за специфики экосистемы (как ловко было указано выше с JavaScript) или специфики вашей команды. Тогда вы можете воспользоваться чем-то одним из нескольких возможных уровней тестирования. Это лучше, чем ничего.
Могу порекомендовать также следующее. Очень помогает, когда автор кода оставляет уже в самом пул реквесте комментарии на свой же код. Пара строк может быстро раскрыть необходимость какого-нибудь не особо эстетичного костыля и заметно упростить жизнь ревьюера. Ну и к этим комментариям также зачастую могут вернуться исследователи кода уже в будущем.
У заканчивающих высшее по направлению шансы, конечно, куда выше, с этим я полностью согласен. В своё время нам Университет даже помогал с трудоустройством. Оказаться без работы при таком раскладе было затруднительно. Хотя уже и тогда была перспектика на пол года или год оказаться на неоплачиваемом месте и трудиться за строку в резюме. Но после этого, насколько я помню, можно было гордо считать себя "мидом" и иметь выбор. Сейчас с этим будет несколько тяжелее.
Если кратко, то на нашей программе был курс о "Качестве ПО" ровно на один семестр. Там была, безусловно, и вода, но саму методологию я подчерпнул оттуда и пользуюсь по сей день. Если будет интерес к продолжению цикла статей, то я с радостью сделаю выдержку из курса.
У вас хороший сетап тестов, и я бы сделал так же. Но с чем именно вы спорите? ?
Добрый день! Это хорошие рассуждения.
Полагаю, можно начать с того, что единственное что вы "должны" - это в контракте с работодателем или с заказчиком, а остальное решается между разрабами, и решается очень по разному.
Описанное вами есть сугубо "мокистский" (очень не люблю это слово) подход. Только заместо "интеграционных" тестов я предпочитаю что-нибудь, что заходило бы через эндпоинты или через event listener, а проверяло бы HTTP Response, сайд эффекты в базе, события, или прочие внешние проявления поведения кода. Это ещё иногда называется фуникциональными тестами, системными, E2E, зависит от команды.
То, что вы называете "не рыба и не мясо" - как раз юнит тестирование по Фаулеру и Хорикову. У них "юнит" это не единица кода, а единица бизнес требований. Если вы почитаете их труды, то они вполне детально объясняют, в чём видят пользу последнего, что я и обсуждаю.
Соответственно, возникает вопрос, что выбрать. Вы можете выбрать всё сразу, но это может быть черезчур. Хотя и такое бывает. Я предпочитаю искать компромисс.
Что касается практик внутри конкретного бизнеса, может доходить до крайнего. Например, весьма непринято погружаться в тестирование у некоторых консалтеров. Такие бизнесы могут ставить своей задачей выдать готовый прототип за 2-3 месяца и отдать его кому-либо на дальнейшее поддержание. Предложение "давайте лучше тестировать" тут могут встретить в штыки. Хотя, повторюсь, крайность.
Добрый день!
Правильно понимаю, что у вас какой-то хардварный кейс? Не могу прокомментировать, потому что с таким не работал. Но был бы очень рад узнать подробности. ?
Интеграционные тесты - очень растяжимое понятие. Если мы говорим о тестах, которые покрывают всю систему целиком, то они не являются заменой unit тестам, тут я с вами согласен. Посыл был скорее в том, что для вас не всегда может быть доступен или возможен какой-то один тип тестирования. Такое может произойти из-за специфики экосистемы (как ловко было указано выше с JavaScript) или специфики вашей команды. Тогда вы можете воспользоваться чем-то одним из нескольких возможных уровней тестирования. Это лучше, чем ничего.
Могу порекомендовать также следующее. Очень помогает, когда автор кода оставляет уже в самом пул реквесте комментарии на свой же код. Пара строк может быстро раскрыть необходимость какого-нибудь не особо эстетичного костыля и заметно упростить жизнь ревьюера. Ну и к этим комментариям также зачастую могут вернуться исследователи кода уже в будущем.
У заканчивающих высшее по направлению шансы, конечно, куда выше, с этим я полностью согласен. В своё время нам Университет даже помогал с трудоустройством. Оказаться без работы при таком раскладе было затруднительно. Хотя уже и тогда была перспектика на пол года или год оказаться на неоплачиваемом месте и трудиться за строку в резюме. Но после этого, насколько я помню, можно было гордо считать себя "мидом" и иметь выбор. Сейчас с этим будет несколько тяжелее.
Добрый день!
Если кратко, то на нашей программе был курс о "Качестве ПО" ровно на один семестр. Там была, безусловно, и вода, но саму методологию я подчерпнул оттуда и пользуюсь по сей день. Если будет интерес к продолжению цикла статей, то я с радостью сделаю выдержку из курса.