А как кстати работает трекер в случае работы за зарплату? Ну т.е. видите к примеру что человек работал сегодня 5ч, а не 8. Вы его вызываете, он говорит что-то — ребенка к врачу надо было сводить, но план за сегодня я выполнил. Что дальше, т.е. будете с них входить в конфликт говоря что, давай 3ч отрабатывай или бери из отпуска или как-то еще?
Это хабр, за это его и приятно читать. Есть еще линкендин, там на подобные статьи только комменты в стиле Great work, Thanks for sharing, Interesting solution и т.д…
А почему 5 часов лучше чем 25? Чем вообще занимается ваша компания? Если это консалтинг, то оплаченные и аргументированные 25 часов за хорошее решение на которое согласен клиент лучше чем 5 часов за решение собранное по быстрому на коленке, ну т.е. банально ваш заработок будет больше
У вас наверное одна команда(или опеределенные люди) имела доступ ко всему(биллинг и запросы к базе данных от сервисов). Если предположить что это совершенно разные команды, с разными менеджерами, то организовать такой проект будет архисложно
Ну еще и смысл им это делать? Ну т.е. потратить кучу времени на переписывание биллинга, чтобы по факту получить убыток, большинство же превышений думаю не такие большие и по факту оплачиваются
Ну т.е. может и да, какой-то тест показал что баг в моем коде, нашли регрессию, отлично. А может и ошибка старого теста, который не учитывает нового поведения(что не очень хорошо).
Ну ложные срабатывания — вы меняете что-то, отваливаются какие-нибудь тесты, вы начинаете разбираться, понимаете что это не баг, а просто кто-то не учел ваше изменение, т.е. надо править тест
Вообще, я бы не стал отделять юнит-тесты от разработки. Это единое целое.
Это тоже сомнительное утверждение. Ну чтобы убедиться что результатом работы можно пользоваться, можно например сделать ручное тестирование(которое все равно надо делать) и не тратить время на написание автотестов.
Возьмите кстати для примера Киберпанк который недавно вышел. Они там и без всяких дополнительных тестов знали что игра содержит кучу багов, но все равное ее зарелизили. Т.е. какой тогда смысл тратить время на юнит-тесты(которые позволят найти еще больше багов), когда баги и так известны. Лучше это время потратить на их исправление
Ну т.е. у вас предположение что наличие юнит тестов понизит кол-во багов? По моему ошибки в любом случае будут, каждая со своей стоимостью решения. пока тут никто не привел конкретных цифр сколько конкретно багов позволило это найти, кол-во затрат времени на написание таких тестов, кол-во ложных срабатываний и время исправления этих ложных срабатываний. Т.е. пока складываеся мнение если мы берем типовое приложение CRUD(где есть работа с базой данных) то трата времени на юнит тестирование это довольно неэффективный способ траты времени
В вашем примере с подпиской это может быть аналогично конкурентам, которые потратят это время на доп. функционал или снижение стоимости подписки
Ну главный вопрос — какой в этом практический смысл. Т.е. меняя что-то(пересчет курсов), я ожидаю что все кто его использовал поменяют поведение. Для этого и нужна ООП собственно. То что они в своих тестах этого не покрыли, это как бы не хорошо, но никакой практической пользы проекту это не несет
Иногда бывает, что добавление функциональности в одном месте ведет к ошибкам в другом, и тесты ловят такой регресс.
Ну мой вопрос как раз об этом. Наверное бывают и случаи когда добавление функциональности в одном месте ведет к ошибкам тестов, которые на самом деле не ошибки, а не учитывают новой фукциональности. И если этот код и тест писался не вами, то это будет уже не 15 минут на исследование и исправление, а на порядок больше времени
Есть к примеру статистика Как часто падают не вами написанные тесты и сколько из них ложных срабатываний
Кстати интерестно, слежу за xamarin, недавно они выпустили какое-то обновление, где как раз показывается как теперь все быстро стало компилится. Или там еще есть другие проблемы?
Если есть чистая функция получает набор сум и курс валют в виде аргументов, а потом складывает и умножает и возвращает рузультат. То можно написать юниттест который прверяет, что складываются и умножаются нужные цифры.
Ну чистых функций в реале практически не бывает. К примеру придется использовать существующий механизм пересчета из разных валют. При этом если заложить конкретные значения, а этот пересчет в дальнейшем поменяют, тест свалится, что не будет ошибкой, а будет ошибкой теста
Это идеальный сценарий :) Есть еще такой
Разработчик минимально тестирует чтобы совсем сразу не падало и отдает аналитику. Аналитик думает — ну разработчик же тестировал, зачем мне напрягаться, передает заказчику. Те в свою очередь думает — ну парни же профи, им можно доверять, переносим на прод…
С генераций тоже проблемы. К примеру даже взять мой простой пример, клиенты бывают локальные, бывают иностранные, валюты в проводках могут быть локальными валютами, могут быть иностранными. Т.е. это уже дает 4 разных комбинации данных. Любой процесс посложнее даст миллион различных комбинаций
если он не учёл все последствия внесения своих изменений, это будет видно на тесте, а не в проде
Ну вот это главное что вызывает вопрос — когда другой разработчик будет писать код, он сознательно меняет логику системы. Опять же для моего примера, изменили мы механизм пересчета курсов(к примеру вышел какой-нибудь банковский приказ, брать курс не на сегодня, а на завтра), все тесты которые считали сумму проводок автоматически стали падать. Какой в этом положительный смысл и кто их должен чинить и главное зачем. Это приведет к огромным затратам на поддержку, без положительного результа
А у вас есть общение с базой данных? Ну т.е. у нас обычно ничего изолированного нет, все строится на общении с общей базой данных. И это похоже ключевой момент, т.е. к примеру пишем код который получает сумму проводок по клиенту в какой-то валюте. Результат будет зависеть от того что есть в базе, его как-бы невозможно предсказать. Ну т.е. можно конечно сгенерить данные, но потом кто-то внесет какое-то изменение и тест свалится
Занимаюсь ERP(Dynamics AX), сотни проектов, типовой это 50-200 активных пользователей с 3-5 разработчиками.
Юнит Тесты никто не пишет, все попытки что-то наладить упирались в трудоемкость разработки и самое главное — поддержки тестов. Типовой флоу — программист что-то делает у себя, отдает аналитику, тот прогоняет тестовые сценарии.
А вы у себя выполняли замеры во сколько вам обходится разработка тестов? Во сколько обходится поддержка(ну т.е. например ложные срабатывания)? И сколько вы реальных ошибок смогли найти используя тесты(ну т.е. ошибки которые бы прошли все остальные стадии проверки, но нашлись только юнит-тестированием)
Некоторое время назад работал на похожем проекте. Т.е. задачу которую вполне по силам сделать 10 людьми делают 100. При чем в этих 100 есть довольно много грамотных людей, но из-за кол-во возникает множество замечательных эффектов, когда принимается какое-нибудь неоптимальное решение, все остальные вместо того чтобы его исправить на корню, исправляют последствия.
Плюс это все дополняется очень слабыми в техническом плане архитекторами, но с отличными soft skill.
Т.е. тут описывается похожая ситуация — у команды была возможность сделать прототип(где как раз надо было бы и продумать все эти моменты). Они его по сути не сделали(это как бы ключевой момент), банально отрапортовав что технология отличная, плюс еще до кучи и остались на своих местах
Если вы живете в мире Optane и NVMe накопителей и думаете что везде так, то это заблуждение. Для примера посмотрите на скорости SSD дисков в Azure. Даже самые производительные и дорогие имеют скорость меньше 10к IOPS, если говорить о среднем сегменте(128-256ГБ), то вообще будет около 500-1000 IOPS. А на Ажур хостятся огромное число приложений.
Я правда сам не понимаю почему так(т.е. USB3 флешка работает быстрее) но эта данность времени. docs.microsoft.com/en-us/azure/virtual-machines/disks-types#disk-size-1
Ну еще и смысл им это делать? Ну т.е. потратить кучу времени на переписывание биллинга, чтобы по факту получить убыток, большинство же превышений думаю не такие большие и по факту оплачиваются
Это тоже сомнительное утверждение. Ну чтобы убедиться что результатом работы можно пользоваться, можно например сделать ручное тестирование(которое все равно надо делать) и не тратить время на написание автотестов.
Возьмите кстати для примера Киберпанк который недавно вышел. Они там и без всяких дополнительных тестов знали что игра содержит кучу багов, но все равное ее зарелизили. Т.е. какой тогда смысл тратить время на юнит-тесты(которые позволят найти еще больше багов), когда баги и так известны. Лучше это время потратить на их исправление
В вашем примере с подпиской это может быть аналогично конкурентам, которые потратят это время на доп. функционал или снижение стоимости подписки
Ну мой вопрос как раз об этом. Наверное бывают и случаи когда добавление функциональности в одном месте ведет к ошибкам тестов, которые на самом деле не ошибки, а не учитывают новой фукциональности. И если этот код и тест писался не вами, то это будет уже не 15 минут на исследование и исправление, а на порядок больше времени
Есть к примеру статистика Как часто падают не вами написанные тесты и сколько из них ложных срабатываний
Это кстати хорошее замечание
Ну чистых функций в реале практически не бывает. К примеру придется использовать существующий механизм пересчета из разных валют. При этом если заложить конкретные значения, а этот пересчет в дальнейшем поменяют, тест свалится, что не будет ошибкой, а будет ошибкой теста
Разработчик минимально тестирует чтобы совсем сразу не падало и отдает аналитику. Аналитик думает — ну разработчик же тестировал, зачем мне напрягаться, передает заказчику. Те в свою очередь думает — ну парни же профи, им можно доверять, переносим на прод…
Ну вот это главное что вызывает вопрос — когда другой разработчик будет писать код, он сознательно меняет логику системы. Опять же для моего примера, изменили мы механизм пересчета курсов(к примеру вышел какой-нибудь банковский приказ, брать курс не на сегодня, а на завтра), все тесты которые считали сумму проводок автоматически стали падать. Какой в этом положительный смысл и кто их должен чинить и главное зачем. Это приведет к огромным затратам на поддержку, без положительного результа
Юнит Тесты никто не пишет, все попытки что-то наладить упирались в трудоемкость разработки и самое главное — поддержки тестов. Типовой флоу — программист что-то делает у себя, отдает аналитику, тот прогоняет тестовые сценарии.
А вы у себя выполняли замеры во сколько вам обходится разработка тестов? Во сколько обходится поддержка(ну т.е. например ложные срабатывания)? И сколько вы реальных ошибок смогли найти используя тесты(ну т.е. ошибки которые бы прошли все остальные стадии проверки, но нашлись только юнит-тестированием)
Плюс это все дополняется очень слабыми в техническом плане архитекторами, но с отличными soft skill.
Т.е. тут описывается похожая ситуация — у команды была возможность сделать прототип(где как раз надо было бы и продумать все эти моменты). Они его по сути не сделали(это как бы ключевой момент), банально отрапортовав что технология отличная, плюс еще до кучи и остались на своих местах
Я правда сам не понимаю почему так(т.е. USB3 флешка работает быстрее) но эта данность времени.
docs.microsoft.com/en-us/azure/virtual-machines/disks-types#disk-size-1