Или завязан на время

Может упростить написание тестов

Не очень, но один из

мне думается что тесты или куски/инструменты тестирования не долны никак всплывать коде который бежит на проде

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

Так ты как я понимаю можешь на этапе тестов мокнуть функции

я только начал изучать go и честно горя не представляю для каких целей такое может понадобиться

ну моки не только в го используются для тестов

https://ru.wikipedia.org/wiki/Mock-%D0%BE%D0%B1%D1%8A%D0%B5%D0%BA%D1%82

я понимаю что это некая концепция которая есть в ООП

но

у меня никогда не было задачи где это могло бы понадобится

это нужно в тестировании

поэтому я эту тему не особо понимаю

или ты просто тесты не пишешь?

я их пишу но очень редко

я под web пишу

и если задача не про API то там тесты редко нужны

а в вебе не используются моки?

ясно

ну я по крайней-мере не видел чтобы кто-то использовал

кроме той статьи на которую ссылка выше есть

я всегда считал, что логику клиента всегда нужно тестить

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

а если ты используешь готовый фреймворк или CMS под которую только отдельные компоненты дописываешь

то тесты туда как-то не очень вписываются

@alex19pov31 Как насчёт тестов твоих отдельных компонентов?

)) можно, но менеджеры на такое время не выделяют

плохие менеджеры

вы вебом занимаетесь ?

зачем морочиться с тестированием UI, если оно хорошо покрывается QA?

автотесты экономят время человеческих ресурсов

то есть вы все используете capybara, selenium, codeseption и пр. ? Для тестирования внешнего вида ?

автотесты экономят время человеческих ресурсов

изначально они расходуют время

клиент - это не всегда только внешний вид

равное и даже большое написанию кода который тестируешь

изначально они расходуют время

только изначально, потом немного на поддержке

не всегда, особенно если речь про UI

когда клиент хочет его переделывать раз в полгода

автотесты экономят время человеческих ресурсов

они экономят время дешевого ручного QA, но требуют время дорого инженера, который всю эту инфру будет поддерживать, борться с flakiness и т.д. Так себе экономия.

если написать и отдать, то да, возможно тесты не нужны, но тогда вопрос изначально неправильно поставлен

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

они экономят время дешевого ручного QA, но требуют время дорого инженера, который всю эту инфру будет поддерживать, борться с flakiness и т.д. Так себе экономия.

в мелких проектах с дешевой раб силой да

что в мелких, что в больших проектах: QA - это дешево, инженер - это дорого :-)

плюс QA все равно нужен, ибо UI тестами все не покроешь и новые фичи не протестишь

что в мелких, что в больших проектах: QA - это дешево, инженер - это дорого :-)

не применимо к гигантской кодовой базе с CD

у меня в задачах имеет ссмысл API покрывать тестами - это оправдывает затраты

у меня в задачах имеет ссмысл API покрывать тестами - это оправдывает затраты

мы вроде про веб компоненты говорили, то бишь UI

не применимо к гигантской кодовой базе с CD

ты сам-то с гигантской кодовой базой без QA работал на одних только автотестах?))

нет, но примеров вебе куча

нет, но примеров вебе куча

от таких же, кто не работал ?

а кто говнеца с тестированием UI вкусил, тот уже не настолько категоричен, что "тесты хорошо, тесты полезны, только QA - это плохо"

я не говорю, что надо только тестами тестировать, никакого QA

а кто говнеца с тестированием UI вкусил, тот уже не настолько категоричен, что "тесты хорошо, тесты полезны, только QA - это плохо"

Поддержу

я говорю, что странно, что человек то программирования не знает что такое мок

я знаю

я говорю, что странно, что человек то программирования не знает что такое мок

пусть даже он и пишет только компоненты к гую

только не пому для чего он в вебе и в тестах

я знаю

"я только начал изучать go и честно горя не представляю для каких целей такое может понадобиться"

Какая разница для чего код?

Для веба или кофеварки

Какая разница для чего код?

поддерживаю

Вычленяешь юнит и тестируешь

я говорю, что странно, что человек то программирования не знает что такое мок

счастливый человек, что не знает. А то меня всегда дрожь пробирает, когда надо большие иерархии мокать. Или разбираться что там намокано в упавшем тесте. Или когда фиксишь за 10 минут и еще полдня пишешь тест, пытаясь все помокать.

ну саму сють мок я понял, что есть несколько окружений и у одного и того же объекта/функции в разных окружениях разная начинка

Селениум это уже функциональные тесты

Вычленяешь юнит и тестируешь

юнит тестами UI не потестируешь)

Протестируешь

Селениум это уже функциональные тесты

а движки для браузеров там для чего тогда ?

Почему нет то?

юнит тестами UI не потестируешь)

логику ui можно

Генерит мой реакт дерево, мне же его рендерить не надо, чтобы проверить

Протестируешь

как ты поехавшие стили протестируешь?

а движки для браузеров там для чего тогда ?

Для чего?

как ты поехавшие стили протестируешь?

Визуальное представление это другое, здесь нужно рендер конкретный тестировать. Но это не отменяет тестов логики генерации

как ты поехавшие стили протестируешь?

тестирование через скриншоты, дифы

тестирование через скриншоты, дифы

в жизни этим занимался когда-нибудь?))

http://joxi.ru/a2XOa3df1L9D5m.jpg - вот это разве не иструмент для тестирования ? и разве это функциональное тестирование ?

в жизни этим занимался когда-нибудь?))

не было необходимости) прост знаю как это делают гиганты (ну в основном)

как ты поехавшие стили протестируешь?

Как вариант - phantom.js и сравнение скриншотов попиксельно, скриншоты он делает из коробки двумя строчками кода

Фантом уже всё

Уже что - всё?)

Как вариант - phantom.js и сравнение скриншотов попиксельно, скриншоты он делает из коробки двумя строчками кода

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

Почил в бозе

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

Я даже больше скажу - есть много платных инструментов для тестирования, в том числе и на базе фантома, но это никто не афиширует

Визуальное представление это другое, здесь нужно рендер конкретный тестировать. Но это не отменяет тестов логики генерации

в общем да, разговор ни о чем. Надо предметно обсуждать конкретный UI, что он делает и что конкретно в нем мы хотим тестировать. ?

Уже что - всё?)

теперь вместо него безголовый хром

А есть и кроссплатформенные, с тестированием под любой браузерный движок, если бюджет позволяет - может серьезно подвинуть QA

Как вариант - phantom.js и сравнение скриншотов попиксельно, скриншоты он делает из коробки двумя строчками кода

ты запаришься стабилизировать тесты и каждый раз разгребать руками упавшие :-)

в общем да, разговор ни о чем. Надо предметно обсуждать конкретный UI, что он делает и что конкретно в нем мы хотим тестировать. ?

А что дискутировать то, нет тестов - значит кодовая база пахнет плохо. Я бы такое не пропустил в прод

ты запаришься стабилизировать тесты и каждый раз разгребать руками упавшие :-)

Тесты - это не панацея. Полностью избавиться от ручного тестирования - не получится, я думаю все здесь это понимают.

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

Тесты - это не панацея. Полностью избавиться от ручного тестирования - не получится, я думаю все здесь это понимают.

просто забавно, что все, кто затирает про то, что тестировать UI - это хорошо, тестировать UI - это нужно, в жизни скорее всего никогда этим не занимались. Еще раз, я не говорю про юнит тесты, которые легко пишут и легко поддерживаются. Я говорю про end2end тесты, где надо поднимать все окружение, создавать акки, предзаполнять их данными, потом запускать тесты, которые будут как-то кликать, скролить, менять UI, потом надо как-то проверифицировать, что тест успешно выполнился, словить кучу проблем с нестабильностью тестов, потом нужно подчищать данные и гасить окружение. В конце концов надо сделать, что это работало быстро (иначе никто запускать не будет). И да, все это дело надо постоянно поддерживать, тесты будут постоянно падать и их надо будет регулярно фиксить. И это не могут делать QA, это работой будет заниматься команда инженеров с соответствующей зарплатой.

просто забавно, что все, кто затирает про то, что тестировать UI - это хорошо, тестировать UI - это нужно, в жизни скорее всего никогда этим не занимались. Еще раз, я не говорю про юнит тесты, которые легко пишут и легко поддерживаются. Я говорю про end2end тесты, где надо поднимать все окружение, создавать акки, предзаполнять их данными, потом запускать тесты, которые будут как-то кликать, скролить, менять UI, потом надо как-то проверифицировать, что тест успешно выполнился, словить кучу проблем с нестабильностью тестов, потом нужно подчищать данные и гасить окружение. В конце концов надо сделать, что это работало быстро (иначе никто запускать не будет). И да, все это дело надо постоянно поддерживать, тесты будут постоянно падать и их надо будет регулярно фиксить. И это не могут делать QA, это работой будет заниматься команда инженеров с соответствующей зарплатой.

ну мы тут в основном про юнит, тема то с моков началась

Если вернуться к теме про моки рантайма го, то кмк, нужда в этом - это показатель непродуманного дизайна

Чуваки, а кто-нибудь юзал пакет jmoiron/sqlx? Выглядит так, что он решает мою проблему с сопоставлением данных из БД и полей в страктах, но мне пока не ясно какой ценой это достигается, надо читать код пакета

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