Здравствуйте, peer, Вы писали:
P>Привет P>Есть какие-то лучшие практики, чтобы понять насколько увеличивается время разработки на таски когда пишутся тесты?
По моему опыту нормальные автотесты увеличивают время разработки в 1.5-2 раза.
Здравствуйте, Maniacal, Вы писали:
M>Здравствуйте, peer, Вы писали:
P>>Привет P>>Есть какие-то лучшие практики, чтобы понять насколько увеличивается время разработки на таски когда пишутся тесты?
M>По моему опыту нормальные автотесты увеличивают время разработки в 1.5-2 раза.
автотесты — это прокликиванием через юай или имеется ввиду тест чисто на бэке но на всю операцию типа СохранениеЗАказа?
Здравствуйте, peer, Вы писали:
P>Привет P>Есть какие-то лучшие практики, чтобы понять насколько увеличивается время разработки на таски когда пишутся тесты?
Тесты ведь не просто груз, который увеличивает время разработки таски. Предпосылка здесь в том, что при росте сложности решения тесты позволят сократить время разработки (таски). Если тесты не позволяют это сделать, то это тесты, написанные зря. Но достаточно хорошо написанные тесты должны дать качественно другую кривую стоимости разработки от сложности решения, чем без тестов. Именно поэтому вопрос "на_сколько увеличится время" не имеет ответа без отсылки к стадии/сложности решения.
Т.е. до того, как кривые стоимости от сложности пересекутся, тесты будут увеличивать время разработки, а после — уменьшать. Это в теории. Практика — она разная. Может быть разной даже для одних и тех же рук/головы и меняться в зависимости от ... всего.
Но в целом — полезнее ответить на другие вопросы. Насколько увеличивается Как меняется время разработки, когда тесты не пишутся? Или что является критерием окончания разработки таски? Или как узнать, что разработка таски N+1 не сломала фукнциональность, достигнутую на N тасках?
Здравствуйте, peer, Вы писали:
P>автотесты — это прокликиванием через юай или имеется ввиду тест чисто на бэке но на всю операцию типа СохранениеЗАказа?
Автотесты это тесты, встроенные непосредственно в программу, когда она сама себя способна тестировать, или в специальную, поставляемую с программой/библиотекой утилиту. Обычно они запускаются автоматически при автосборке или вручную, после внесения доработок, чтобы проверить не сломалось ли что-то из того, что до этого работало.
Здравствуйте, Maniacal, Вы писали:
M>Здравствуйте, peer, Вы писали:
P>>автотесты — это прокликиванием через юай или имеется ввиду тест чисто на бэке но на всю операцию типа СохранениеЗАказа? M>Автотесты это тесты, встроенные непосредственно в программу, когда она сама себя способна тестировать, или в специальную, поставляемую с программой/библиотекой утилиту. Обычно они запускаются автоматически при автосборке или вручную, после внесения доработок, чтобы проверить не сломалось ли что-то из того, что до этого работало.
другое название интеграционные тест? я просто думал автотесты — это симуляция действий юзера именно
Здравствуйте, samius, Вы писали:
S>Здравствуйте, peer, Вы писали:
S>Т.е. до того, как кривые стоимости от сложности пересекутся, тесты будут увеличивать время разработки, а после — уменьшать.
я думаю тут никто никогда не скажет четко ничего.
S> Или что является критерием окончания разработки таски?
кстати у нас это тоже в дебатах. имхо, тут надо на спеку ориентироваться. качественное тз — результат не хз
S>Или как узнать, что разработка таски N+1 не сломала фукнциональность, достигнутую на N тасках?
так по идее если есть автотест на каждую фичу и коммитим только когда все тесты зеленые, то легко понять кто сломал тесты
Здравствуйте, peer, Вы писали:
P>другое название интеграционные тест? я просто думал автотесты — это симуляция действий юзера именно
Когда я с термином "Автотесты" столкнулся впервые в начале 2000-х в крупной конторе, там имелось в виду, что это тесты, которые автоматически запускает автосборщик на репозитории во время автоматических ночных билдов и тест в stdout должен вернуть FAILED или OK. С текущим проектом в текущей конторе я сделал утилиту, которая методично проходится по всей функциональности серверного приложения и сверяет результат с шаблонным. Так как пользовательского интерфейса, считай, нет, всё проверяется через API. В начале 2000-х в той же конторе, про которую я писал вначале поста, в отделе тестирования были утилиты-роботы, которые имитировали действия пользователя. Какой-то термин там для них использовался отдельный, но уже не вспомню.
В любом случае, автотесты, думаю, это все тесты, которые запускаются и не требуют от пользователя дополнительных телодвижений, сами проверяя корректность работы системы.
P>насколько увеличивается время разработки на таски когда пишутся тесты?
Решаем задачу в чьих интересах и на каком таймфрейме? Разработчику закрыть таск и сдать тестерам, или предприятию закрыть проект и сдать комиссии заказчика? (Разработчику за успех предприятия могут вместо премии просто вспомнить просрочки по таскам).
Здравствуйте, peer, Вы писали:
P>насколько увеличивается время разработки на таски когда пишутся тесты?
В смысле "увеличивают"? Написание ПО подразумевает разработку кода продукта и кодов тестов. Оценка задачи без учета времени на написание авто-тестов — это абсурд. Тесты — неотъемлемая часть продукта особенно если настроен цикл CI/CD с контролем качества в каком-нибудь статическом анализаторе кода (типа SonarQube и тд), в этом случае coverage ниже допустимого просто запретит интеграцию ветки.
Сейчас даже на олимпиадах тесты пишут (на ввод данных и вывод) и время олимпиады включает в себя написание кода и тестов.
PS. Мелкое ПО можно писать без тестов, но с каждым 10K CLOC стоимость поддержки этого ПО будет расти экспоненциально. И в этом случае если на первых порах SDET может писать 150-400 CLOC в день, то при росте продукта это легко перерастет в 100 CLOC в два дня с постоянным фиксом багов.
P>Есть какие-то лучшие практики, чтобы понять насколько увеличивается время разработки на таски когда пишутся тесты?
Как правило, время не увеличивается, а уменьшается. Особенно если учесть время на ручное тестирование, которое понадобится для _ВСЕХ_ изменений, которые будут осуществлены в любой части продукта ПОСЛЕ завершения этой задачи.
Здравствуйте, peer, Вы писали:
P>Привет P>Есть какие-то лучшие практики, чтобы понять насколько увеличивается время разработки на таски когда пишутся тесты?
В моменте, тесты увеличивают сроки, на длинной дистанции — уменьшают т.к. уменьшается количество багов и улучшается общее качество кода (да-да, тестсируемый код заставляет соблюдать принципы проектирования), для отладки кусков задачи можно прогонять тест, а не собирать продукт целиком. Без тестов имеет смысл писать если работа на один раз или лично ты после написания части кода получишь бонус и отвалишь из контры либо с проекта.
Здравствуйте, peer, Вы писали:
P>Привет P>Есть какие-то лучшие практики, чтобы понять насколько увеличивается время разработки на таски когда пишутся тесты?
Такой вопрос не имеет смысла. Если вам его задают, дайте ответ, который позволит вам далее комфортно существовать в компании. Если сами для себя задаётесь вопросом — почитайте книжки, поэкспериментируйте. Это примерно как перерывы на покурить: можно писать код и без них, но если вы к ним привыкли, без них будет плохо.
