Прост как бревно. Thats all about it.

Прост как бревно. Thats all about it.

Тоесть для старта изучения мира кода, это хороший вариант?

А чего не питон?

Нет, для старта изучения мира кода лучше Python.

Луа простой, транслируемый в си язык, хорошо подходящий для тупых ботиков и встраеваемого по.

На работе предложили начать учить автоматизацию, и есть инструмент который работает с lua

На работе предложили начать учить автоматизацию, и есть инструмент который работает с lua

Что за инструмент?

Я так понимаю он создан в нашей компании

Называется Colibri

на Selenium IDE похоже

Я на 99.3% уверен что это спиженно и слегка переписанно

Вообще багованый сам по себе инструмент

Но работает

Если 90% багов в проекте - что код ссылается на несуществующую переменную, или где-то там ассайнмент не происходит - юниты дают очень большой выхлоп.

Юнит-тесты гарантируют при должном покрытии, что таких ошибок нет. Если юнит-тестов нет, то эти ошибки будут всплывать при более высокоуровневом тестировании.

Юнит-тесты гарантируют при должном покрытии, что таких ошибок нет. Если юнит-тестов нет, то эти ошибки будут всплывать при более высокоуровневом тестировании.

Только при условии, что они есть.

Только при условии, что они есть.

Только, как ты можешь быть уверен, что их нет, не протестировав?

Только, как ты можешь быть уверен, что их нет, не протестировав?

Если их исторически нет, то покрытие юнитами профита не даст.

Исторически? Я же не предлагаю легаси код брать и юнитами покрывать. Я утверждаю, что новый код для продакшен систем, должен покрываться юнит-тестами.

В подавляющем большинстве случаев.

В подавляющем большинстве случаев.

Воистину, вам надо больше с деньгами/оценками затрат работать

Чтобы бы понять что в реальности, в подавляющем большинстве случаев, все наоборот

Воистину, вам надо больше с деньгами/оценками затрат работать

Расскажите мне про низкие затраты на поддержку говнокода. Или в подавляющем большинстве случаев мы как-то сдали проект и забыли?

Исторически? Я же не предлагаю легаси код брать и юнитами покрывать. Я утверждаю, что новый код для продакшен систем, должен покрываться юнит-тестами.

Причем тут легаси? Вот у вас есть разработчик, который и так выдает код высокого качества. Профит от юнитов на его коде - минимален.

То есть нормального кода без тестов быть не может?

Зачем тратить на это время？Правильно, не за чем.

Это утверждения из разряда: а зачем вообще тратить время на тестирование, если код высого качества, да и разработчик у нас умный, постановки с полпинка понимает.

Да, и одни сеньоры на проекте.

С офигенным кодом и мы в этом уверены на 100%.

Передергиваете

Поэтому принятие решения о пользе юнитов стоит делать на основе каких то показателей, а не потому что практика хорошая.

Передергиваете

Нет. Это вы какую-то идеальную ситуацию описываете.

Высокое качество кода не гарантирует верную бизнес логику приложения

И да, я работал с разработчиками, которым не нужно тестирование примерно совсем.

Ну в реальности, никто никакую оценку трудозатрат и профита не проводит. Если у разрабов есть умение и воля писать тесты - они пишут. Если нет - не пишут. И никакие графики и калькуляции не помогут.

Ну в реальности, никто никакую оценку трудозатрат и профита не проводит. Если у разрабов есть умение и воля писать тесты - они пишут. Если нет - не пишут. И никакие графики и калькуляции не помогут.

Хохохо

Высокое качество кода не гарантирует верную бизнес логику приложения

Высокое качество кода гарантирует, что код легко поддерживается и дополняется, что важно для бизнес-логики.

Ну в реальности, никто никакую оценку трудозатрат и профита не проводит. Если у разрабов есть умение и воля писать тесты - они пишут. Если нет - не пишут. И никакие графики и калькуляции не помогут.

У вас какая то другая реальность.

У вас какая то другая реальность.

+

У вас какая то другая реальность.

Приведите пример

Ну в реальности, никто никакую оценку трудозатрат и профита не проводит. Если у разрабов есть умение и воля писать тесты - они пишут. Если нет - не пишут. И никакие графики и калькуляции не помогут.

Лол. Тут соглашусь с отсальными.

Приведите пример

Банальный пример сроки

Всем плевать что вы будете делать, есть срок- завтра

Банальный пример сроки

Я прошу пример графика и таблички с оценками

И да, я работал с разработчиками, которым не нужно тестирование примерно совсем.

Шу, ты счастливчик. :)

И никто слушать не будет про тесты

И никто слушать не будет про тесты

Так никто и спрашивать не будет про тесты ) Если надо - тесты будут написаны.

Всем плевать что вы будете делать, есть срок- завтра

Нахер так работать. Менеджмент - говно в таком случае.

Так никто и спрашивать не будет про тесты ) Если надо - тесты будут написаны.

Скорее всего не будут

Хотя бы базовые.

Нахер так работать. Менеджмент - говно в таком случае.

Он вам бабки платит

Шу, ты счастливчик. :)

Нет, я просто реально смотрю на вещи. Есть моменты, когда юниты нужны, есть когда не нужны. С тестированием то же самое.

Нет, я просто реально смотрю на вещи. Есть моменты, когда юниты нужны, есть когда не нужны. С тестированием то же самое.

Но в большинстве случаев нужны. Или так, во всех проектах, где я работал, они были нужны. Если это не прототипы.

Так тут мне хоть кто-то сможет привести реальный пример, когда в компании проводился замер метрики производительности команды с тестами и без?

Он вам бабки платит

Бабки много кто готов платить.

В большинстве проектов где я работал юниты, при довольно неплохом покрытии, давали минимум пользы.

Бабки много кто готов платить.

Не отрицаю

Мало кто готов их платить просто так

В большинстве проектов где я работал юниты, при довольно неплохом покрытии, давали минимум пользы.

А как ты это оценил?

А как ты это оценил?

По статистике их падений, например？

Я был раньше вашей позиции, Александр

Пока реально не начал считать цифры

И прислушался к опытным девелоперам

По статистике их падений, например？

Ты учитывал статистику локального падения у разраба?

Ты учитывал статистику локального падения у разраба?

Йеп.

O_o

Как?

Есть отличные инструменты для этого, типа coverals

Есть отличные инструменты для этого, типа coverals

Чет не гуглится

Coveralls же про покрытие?

Coveralls же про покрытие?

А вот

Он про покрытие, но он может писать статистику покрытия и результат запуска локального рана.

Дальше уже вопрос того, что с этим делать :)

И да, я работал с разработчиками, которым не нужно тестирование примерно совсем.

Есть у нас пара таких прогеров, но формальная проверка какая никакая все таки производится

Хотя я бы не перепроверял))

Он про покрытие, но он может писать статистику покрытия и результат запуска локального рана.

Он прямо после локального рана шлет статистику на сервер какой-то?

Не увидел этого в описании.

Он прямо после локального рана шлет статистику на сервер какой-то?

Каверелс пишет результат измерения покрытия в локальный файл.

Там на сайте все про кавередж, а не про падения тестов.

Могу как будет время погуглить тулзу, которую мы использовали, но суть та же.

Вы меня все равно не убедили по поводу юнит-тестирования. :) Но новое я узнал, это круто. :)

Саша, вопрос не в том, что юниты не нужны. Вопрос в том, что тратить +0.3 времени разработки не осознавая что это дает в результате - довольно странный подход.

Если вы поресерчили и поняли, что это сильно помогает отлаживать (или наоборот, куа жалуются, что качечство билдов низкое, а юнитов нет) - надо лоббировать эту тему.

Если вы понимаете (изучив вопрос), что это не дает профита команде, а просто best practice - ну хер знает, насколько это честно по отношению к работодателю.

Я видел и такие случие, и такие, и те, где 80% падений случайные, а оставшиеся 20 приходятся на одного разработчика.

И тут уж лучше его в пару с кем нибудь посадить, профита больше будет.

Так то понятно, что с юнитами спокойнее, вопрос в том, сколько денег компания тратит на то, что б куа ощущал жопку в тепле.

Как?

Кстати, погуглил, идея умеет сама экспортить результаты локальных прогонов в хмл, если интересно.

Кстати, погуглил, идея умеет сама экспортить результаты локальных прогонов в хмл, если интересно.

Круто, я это буду иметь ввиду на будущее. Наверняка, есть и другие способы. Я просто об этом и не думал никогда.

Ну, в общем было бы желание :)

Ну да, без юнитов разработка более уверенно проводит рефакторинг

И увереннее смотрит в будущее

Вам не придется волноваться об упавших тестах, если их нет

Сам по себе показатель падения юнит тестов мало о чем скажет. У юнитов тоже есть показатель "качество теста". Если разработчик сам убежденный tdd-шник, тогда юнитам можно верить. Если ж юниты пишутся только потому, что у тебя для проекта стоит бизнес метрика "code coverage 80%> то юниты могут писаться задней пяткой, и не панацея вообще. А оценить качество покрытия юнит тестами - та еще задачка.

Если вы понимаете (изучив вопрос), что это не дает профита команде, а просто best practice - ну хер знает, насколько это честно по отношению к работодателю.

Честно. Потому что ты в роли разработчика, а не бизнесмена. Ты должен давать продукт качественный и давать правдивую инфу о рисках

И да, следовать бест практис

Вводить и требовать покрытия кода юнит тестами далеко не всегда разумно. Подсадить на опиум "красный-зеленый-рефакторинг" - это практически для всех проектов клёво. Кроме, может, мвп.