@qa_ru

Страница 701 из 1080
Shoo
29.09.2017
14:06:55
Прост как бревно. Thats all about it.

PERDUCK
29.09.2017
14:07:51
Прост как бревно. Thats all about it.
Тоесть для старта изучения мира кода, это хороший вариант?

Richard
29.09.2017
14:08:06
А чего не питон?

Shoo
29.09.2017
14:08:11
Нет, для старта изучения мира кода лучше Python.

Google
Shoo
29.09.2017
14:08:35
Луа простой, транслируемый в си язык, хорошо подходящий для тупых ботиков и встраеваемого по.

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

PERDUCK
29.09.2017
15:16:44
Я так понимаю он создан в нашей компании

Называется Colibri



Alex
29.09.2017
15:17:57
на Selenium IDE похоже

PERDUCK
29.09.2017
15:18:41
Я на 99.3% уверен что это спиженно и слегка переписанно

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

Но работает

Aleksandr
29.09.2017
17:35:18
Если 90% багов в проекте - что код ссылается на несуществующую переменную, или где-то там ассайнмент не происходит - юниты дают очень большой выхлоп.
Юнит-тесты гарантируют при должном покрытии, что таких ошибок нет. Если юнит-тестов нет, то эти ошибки будут всплывать при более высокоуровневом тестировании.

Aleksandr
29.09.2017
17:57:21
Только при условии, что они есть.
Только, как ты можешь быть уверен, что их нет, не протестировав?

Google
Shoo
29.09.2017
17:57:54
Только, как ты можешь быть уверен, что их нет, не протестировав?
Если их исторически нет, то покрытие юнитами профита не даст.

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

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

Alexey
29.09.2017
18:11:49
В подавляющем большинстве случаев.
Воистину, вам надо больше с деньгами/оценками затрат работать

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

Aleksandr
29.09.2017
18:14:28
Воистину, вам надо больше с деньгами/оценками затрат работать
Расскажите мне про низкие затраты на поддержку говнокода. Или в подавляющем большинстве случаев мы как-то сдали проект и забыли?

Shoo
29.09.2017
18:15:05
Исторически? Я же не предлагаю легаси код брать и юнитами покрывать. Я утверждаю, что новый код для продакшен систем, должен покрываться юнит-тестами.
Причем тут легаси? Вот у вас есть разработчик, который и так выдает код высокого качества. Профит от юнитов на его коде - минимален.

Alexey
29.09.2017
18:15:13
То есть нормального кода без тестов быть не может?

Shoo
29.09.2017
18:15:31
Зачем тратить на это время?Правильно, не за чем.

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

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

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

Alexey
29.09.2017
18:18:25
Передергиваете

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

Aleksandr
29.09.2017
18:19:07
Передергиваете
Нет. Это вы какую-то идеальную ситуацию описываете.

Alexey
29.09.2017
18:19:12
Высокое качество кода не гарантирует верную бизнес логику приложения

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

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

Aleksandr
29.09.2017
18:20:13
Высокое качество кода не гарантирует верную бизнес логику приложения
Высокое качество кода гарантирует, что код легко поддерживается и дополняется, что важно для бизнес-логики.

Google
Pavel
29.09.2017
18:20:40
Alexey
29.09.2017
18:21:01
Приведите пример
Банальный пример сроки

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

Pavel
29.09.2017
18:21:21
Банальный пример сроки
Я прошу пример графика и таблички с оценками

Alexey
29.09.2017
18:21:27
И никто слушать не будет про тесты

Pavel
29.09.2017
18:21:58
И никто слушать не будет про тесты
Так никто и спрашивать не будет про тесты ) Если надо - тесты будут написаны.

Aleksandr
29.09.2017
18:22:08
Всем плевать что вы будете делать, есть срок- завтра
Нахер так работать. Менеджмент - говно в таком случае.

Pavel
29.09.2017
18:22:17
Хотя бы базовые.

Shoo
29.09.2017
18:22:29
Шу, ты счастливчик. :)
Нет, я просто реально смотрю на вещи. Есть моменты, когда юниты нужны, есть когда не нужны. С тестированием то же самое.

Aleksandr
29.09.2017
18:23:26
Нет, я просто реально смотрю на вещи. Есть моменты, когда юниты нужны, есть когда не нужны. С тестированием то же самое.
Но в большинстве случаев нужны. Или так, во всех проектах, где я работал, они были нужны. Если это не прототипы.

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

Aleksandr
29.09.2017
18:23:54
Он вам бабки платит
Бабки много кто готов платить.

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

Alexey
29.09.2017
18:24:07
Google
Alexey
29.09.2017
18:24:17
Мало кто готов их платить просто так

Shoo
29.09.2017
18:25:18
А как ты это оценил?
По статистике их падений, например?

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

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

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

Aleksandr
29.09.2017
18:25:54
По статистике их падений, например?
Ты учитывал статистику локального падения у разраба?

Aleksandr
29.09.2017
18:26:23
O_o

Как?

Shoo
29.09.2017
18:26:47
Есть отличные инструменты для этого, типа coverals

Aleksandr
29.09.2017
18:27:51
Coveralls же про покрытие?

Alexey
29.09.2017
18:28:06
Shoo
29.09.2017
18:28:28
Он про покрытие, но он может писать статистику покрытия и результат запуска локального рана.

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

Konstantin
29.09.2017
18:28:53
И да, я работал с разработчиками, которым не нужно тестирование примерно совсем.
Есть у нас пара таких прогеров, но формальная проверка какая никакая все таки производится

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

Aleksandr
29.09.2017
18:30:35
Он про покрытие, но он может писать статистику покрытия и результат запуска локального рана.
Он прямо после локального рана шлет статистику на сервер какой-то?

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

Google
Shoo
29.09.2017
18:31:13
Он прямо после локального рана шлет статистику на сервер какой-то?
Каверелс пишет результат измерения покрытия в локальный файл.

Aleksandr
29.09.2017
18:32:00
Там на сайте все про кавередж, а не про падения тестов.

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

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

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

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

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

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

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

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

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

Aleksandr
29.09.2017
18:44:43
Кстати, погуглил, идея умеет сама экспортить результаты локальных прогонов в хмл, если интересно.
Круто, я это буду иметь ввиду на будущее. Наверняка, есть и другие способы. Я просто об этом и не думал никогда.

Shoo
29.09.2017
18:45:16
Ну, в общем было бы желание :)

Vyacheslav
29.09.2017
18:52:08
Ну да, без юнитов разработка более уверенно проводит рефакторинг

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

Pavel
29.09.2017
19:40:50
Вам не придется волноваться об упавших тестах, если их нет

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

Add
29.09.2017
21:47:27
Если вы понимаете (изучив вопрос), что это не дает профита команде, а просто best practice - ну хер знает, насколько это честно по отношению к работодателю.
Честно. Потому что ты в роли разработчика, а не бизнесмена. Ты должен давать продукт качественный и давать правдивую инфу о рисках

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

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

Страница 701 из 1080