Вы не ошибаетесь, наследование рабочий инструмент и принцип очень важен. Я говорю о случае, когда наследование вводиться из-за желания переиспользовать код. Вариант с отдельным сервисом даст более «чистый» код.
Очень сложно ответить на вопрос, с данным примером. Формально вы правы, мест для изменения больше. Вот только, в практике я с тами мало встречался. Если это рефакторинг снижающий технический долг, то он направлен на упрощение юнита, однако переход от boolean к ItemState увеличивает complexity. Если у вас рефакторинг обусловлен бизнес задачей, то скорее всего решение будет сложнее, больше юнитов будет вовлечено, но каждый юнит сам по себе должен быть простым и укладываться в 1-9 тест кейсов.
Как вы решаете проблем у с большим каскадом изменений в тестах, после изменений вроде описанного выше?
Стараюсь избегать комбинаторных взрывов при рефакторинг. Существуют практики, которые позволяют решить данную проблему. Основная идея — Не революция, а эволюция маленькими шагами. Можно создать ICache2 с новым методом, и не спешно переводить код на использование новой сигнатуры.
Еще одна мысль. Тесты существуют не для снижения сложности рефакторинга, а для увеличения качества кода. Они в автоматическом режиме позволяют ответить на вопрос — работает ли ваш код, как ожидается.
Использовать композицию из различных сервисов, которые объявляются как зависимости юнита.
Для примера: скажем есть контроллеры и часть из них используют проверку прав пользователя, можно сделать BaseController и наследники через protected функцию будут проверять права пользователя. Я так предлагаю не делать.
Вместо этого, общий код выноситься в сервис и каждый контроллер, которому этот код нужен объявляет от него зависимость.
Добрый день, рефакторинг не представляет проблем — моки строго типизированы и в целом весь код очень дружественен к инструментам автоматического рефакторинга.
Баги можно ловить юнит тестами. Есть два ярких случая:
1. Код с неочевидным поведением — при прочтении кода, не понятно как код себя ведет. Примеры такого кода любят давать на собеседовании, на проверку знаний спецификации языка или среды.
2. Код с вычислениями — в вычислениях могут существовать критические случаи, которые в повседневном использовании редко возникают, и как следствие их сложно найти. Юнит тесты сразу позволяют проверить как поведет себя код в этих условиях.
По третьему вопросу: я планирую еще одну статью, где на примере хочу показать как мы это делаем, пока статьи нет, вы можете найти меня в скайпе по нику и можем обсудить, как вам улучшить ситуацию.
Вы не расскажите, как вы пришли к выводу, что это дорогое удовольствие?
Могу я предположить, что у вас уходило много усилий, что бы разобраться, как их эффективно писать?
Очень интересно было бы взглянуть на это со стороны начальника. У вас случайно нет данных, как начальник оценивает тестирование? Какими цифрами оперирует?
Понял.
Подход имеет право существовать. Заказчик — барин.
Интересно было бы узнать как управленец в целом видит разработку, управление инженерными рисками, и как он это все оценивает.
Если у вас такие проекты идут постоянно, то можно попробовать порефликсировать на тему, что можно улучшить в разработке, не в ущерб приоритетам управленца. Возможно, добавить какие то практики будет не так страшно.
Спасибо за статью, очень интересно.
Меня как программиста интересует вопрос — а выбор технологий, подходов к реализации входит в компетенцию оценки экономики проекта?
3. кому-то выполнить и оценить результаты (они ведь не автоматические).
Мне кажется вы тут ошиблись. Смысл автоматизированных тестов — это возможность их работы без участия человека. Нажали кнопку и на выходи получили знание — тесты прошли или нет.
критерии и нормы закладываются ещё до того, как программист начинает что-то писать
Вы описываете waterfall подход?
У меня таких проектов очень давно не было, сейчас везде agile и lean подходы. Ничего заранее не делается, кроме бизнес историй, да и те по мере надобности детализируються.
Мы тут находимся немного в вакууме и рассматриваем сферу.
Вопрос: зачем программист повторно тестирует код, если за это уже платят другому человеку?
Конечная цель же не платить человеку, а разработать качественный софт. Где-то мы сравнили два подхода и подсчитали, что выгодней разделить разработку и тестирование. Именно поэтому у нас появился тестировщик.
Тут очень много вопросов к сравнили и подсчитали. Что, как, какие сценарии рассматривались.
В целом, тестов никогда не бывает много. Конечное качество продукта достигается эшелонированием разных подходов. Они дополняют друг друга. И юнит тесты и акцептант тесты и ручное тестирование — они независимо ценны.
Вопрос: зачем тратить ресурсы на то, что не приносит прибыль (или даже убытки)?
Опять это вопрос к бизнесу, и это сильно зависит от проекта и конкретных обстоятельств.
Приведу случай из практики. Бизнес тратит 100т денег каждый месяц на разработку проекта в течении полтора года, подписывает контракт на поставку проекта. Готовый продукт имеет проблему, по контракту бизнесу приходиться выплатить компенсацию в размере 10 миллионов денег.
Противоположный случай можно придумать — сайт Василия Пупкина. Ни тестировать, ни заходить на него нет никакого смысла.
Большенство интересуемся нас случаем будут по средине, я думаю.
Статья написана оценочно, на основе опыта, для предметного разговора нужно оперировать измеримыми показателями и их значениями. Скажем, временем и стоимостью разработки. Но нет такого, что мы делаем проект без тестов и потом его же, но с тестами и сравниваем скорость и стоимость.
Опять же, скорость и время не всегда приоритетные показатели, качество продукта и стоимость его содержания (поддержки) может быть приоритетней.
Тут программисту важно понимать, экономические последствия своих решений. Если это proof of concept, то его нужно сделать быстро, не заботясь о качестве. Эта работа — одноразовая. Если нам нужно сделать быстро, качественно и дешево, то ищем другой проект ;-).
Есть и другой аспект, а как ценить влияние тестов на качество архитектуры проекта? А они влияют. Скажем, если хочется сгруппировать тесты, то скорее всего нарушен принцип Single responsibility и можно изменить композицию продакшн юнитов. Если количество тест кейсов больше 7, то с продакшен юнитом что то не так. Тесты помогают вывести улучшенную версию кода. Но архитектура проекта — это внутренний показатель (попробуй его еще оцени) и напрямую его не видно.
Так что считаю что мы вымирающий вид. Технологические динозавры.
Не соглашусь. У нас, по сравнению с остальными есть преимущество в качестве и в экономике проекта. Эволюционно именно команды использующие TDD или просто автоматические тесты выигрывают на длинной дистанции.
Стараюсь избегать комбинаторных взрывов при рефакторинг. Существуют практики, которые позволяют решить данную проблему. Основная идея — Не революция, а эволюция маленькими шагами. Можно создать ICache2 с новым методом, и не спешно переводить код на использование новой сигнатуры.
Еще одна мысль. Тесты существуют не для снижения сложности рефакторинга, а для увеличения качества кода. Они в автоматическом режиме позволяют ответить на вопрос — работает ли ваш код, как ожидается.
Для примера: скажем есть контроллеры и часть из них используют проверку прав пользователя, можно сделать BaseController и наследники через protected функцию будут проверять права пользователя. Я так предлагаю не делать.
Вместо этого, общий код выноситься в сервис и каждый контроллер, которому этот код нужен объявляет от него зависимость.
Баги можно ловить юнит тестами. Есть два ярких случая:
1. Код с неочевидным поведением — при прочтении кода, не понятно как код себя ведет. Примеры такого кода любят давать на собеседовании, на проверку знаний спецификации языка или среды.
2. Код с вычислениями — в вычислениях могут существовать критические случаи, которые в повседневном использовании редко возникают, и как следствие их сложно найти. Юнит тесты сразу позволяют проверить как поведет себя код в этих условиях.
По третьему вопросу: я планирую еще одну статью, где на примере хочу показать как мы это делаем, пока статьи нет, вы можете найти меня в скайпе по нику и можем обсудить, как вам улучшить ситуацию.
Могу я предположить, что у вас уходило много усилий, что бы разобраться, как их эффективно писать?
Подход имеет право существовать. Заказчик — барин.
Интересно было бы узнать как управленец в целом видит разработку, управление инженерными рисками, и как он это все оценивает.
Если у вас такие проекты идут постоянно, то можно попробовать порефликсировать на тему, что можно улучшить в разработке, не в ущерб приоритетам управленца. Возможно, добавить какие то практики будет не так страшно.
Меня как программиста интересует вопрос — а выбор технологий, подходов к реализации входит в компетенцию оценки экономики проекта?
Мне кажется вы тут ошиблись. Смысл автоматизированных тестов — это возможность их работы без участия человека. Нажали кнопку и на выходи получили знание — тесты прошли или нет.
Вы описываете waterfall подход?
У меня таких проектов очень давно не было, сейчас везде agile и lean подходы. Ничего заранее не делается, кроме бизнес историй, да и те по мере надобности детализируються.
Тут не совсем понятно, бизнес не рассчитывает на окупаемость вложений? Ресурсы вкладываются просто так?
Конечная цель же не платить человеку, а разработать качественный софт. Где-то мы сравнили два подхода и подсчитали, что выгодней разделить разработку и тестирование. Именно поэтому у нас появился тестировщик.
Тут очень много вопросов к сравнили и подсчитали. Что, как, какие сценарии рассматривались.
В целом, тестов никогда не бывает много. Конечное качество продукта достигается эшелонированием разных подходов. Они дополняют друг друга. И юнит тесты и акцептант тесты и ручное тестирование — они независимо ценны.
Опять это вопрос к бизнесу, и это сильно зависит от проекта и конкретных обстоятельств.
Приведу случай из практики. Бизнес тратит 100т денег каждый месяц на разработку проекта в течении полтора года, подписывает контракт на поставку проекта. Готовый продукт имеет проблему, по контракту бизнесу приходиться выплатить компенсацию в размере 10 миллионов денег.
Противоположный случай можно придумать — сайт Василия Пупкина. Ни тестировать, ни заходить на него нет никакого смысла.
Большенство интересуемся нас случаем будут по средине, я думаю.
Опять же, скорость и время не всегда приоритетные показатели, качество продукта и стоимость его содержания (поддержки) может быть приоритетней.
Тут программисту важно понимать, экономические последствия своих решений. Если это proof of concept, то его нужно сделать быстро, не заботясь о качестве. Эта работа — одноразовая. Если нам нужно сделать быстро, качественно и дешево, то ищем другой проект ;-).
Есть и другой аспект, а как ценить влияние тестов на качество архитектуры проекта? А они влияют. Скажем, если хочется сгруппировать тесты, то скорее всего нарушен принцип Single responsibility и можно изменить композицию продакшн юнитов. Если количество тест кейсов больше 7, то с продакшен юнитом что то не так. Тесты помогают вывести улучшенную версию кода. Но архитектура проекта — это внутренний показатель (попробуй его еще оцени) и напрямую его не видно.