Тестирование в Go: от плохого к хорошему

[@sallibiker3791]

Братан, хорош, давай, давай, вперёд! Контент в кайф, можно ещё? Вообще красавчик! Можно вот этого вот почаще?

[@emotional_stuff]

экстримЦодовец

[@artik3386]

классный видос. Спасибо. Круто что в контексте чистой архитектуры рассмотрели тестирование. Но хочется дальше. Самое интересное же. Тестирование АПИ и E2E тесты. Буду ждать следующий видос )

[@dmitriy-burov]

Спасибо за видео! Очень полезно было узнать что-то новое и получить ещё большую мотивацию их писать) P.S. Очень хотелось бы видео по чистой архитектуре с примерами (я её использую, но боюсь что не совсем правильно).

[@imbalos]

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

[@r-morozov]

Видео супер! в юнит тестах actual и expected ошибки надо местами поменять. У вас в expected реальная ошибка (должно быть ожидаемая), а в actual ожидаемая (должно быть настоящая)

[@rumartru]

Спасибо! Было интересно. Надеюсь будет продолжение.

[@alexzav1327]

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

[@VitaminessBlues]

Просто, понятно, полезно! Круто, что материал дан в контексте архитектуры! Спасибо!

[@alexanderyurkin9363]

Большое спасибо, очень полезно. Буду рад продолжению

[@denweles6036]

Спасибо за труд! Доходчиво, качественно... правда, были моменты, когда кода не видно было... С тестами только знакомлюсь... хотелось бы побольше узнать по fake, stub и mock, причем с примерами пожестче... без библиотек.

[@zuzexsupportonline]

Очень круто!! Спасибо за большую работу! Я пишу на руби и интересно как работают в других языках, в рубях очень крутой rspec )

[@sovrinfo]

Большое спасибо за видео, сделайте еще продолжение!!!

[@ТимофейЁлкин-о9е]

Респект автору! Было интересно.

[@ОлегНиколаевич-в2р]

Спасибо. Сделайте пожалуйста обучалку по чистой архитектуре в контексе языка Golang

[@ziliboba73]

Спасибо, все очень лаконично, полезно и по делу!

[@alekseybudaev2135]

Люди которые пользуются белой темой оказываются существуют.

[@senior_stepik]

Меня за это часто подъё, но я на темной вообще ничего не вижу, могу пользоваться только светлой, так что да, мы существуем)

[@insentijke]

Спасибо. Очень крутой урок

[@ИванКозлов-ь8ъ]

В целом := очень интересно. Но звучат странные фразы, например := "Мы не можем всё время держать базу чтобы гонять тесты". Ну блин если в озоне на это ресурсов нет, то я хз, надо из айти уходить наверное panic("Remowe all work"). Достаточно просто вроде собрать docker-compose. И делать up -d а потом down -v. Вот мы и стали мочь гонять тесты с поднятой рядом СУБД. А если учесть, что - это всё МС архитектура. Так в докер-композе у нас одна БД и максимум сверху + кафка/кролик, редис, s3, sso, nginx и gateway. И вроде бы мы не на расбери пай код кодим то. Чё нет то? А я уже знаю чё нет то - схема := бублик и каноны. А возможность

[@АлексейТалан-э8ь]

Пишу в комментариях. Посмотрел 2 видео, отличный материал.

[@sergeyshlykov1305]

Да, тема тестирования и рефакторинга очень интересная

[@madbad1310]

Спасибо за видео!

[@nurlanikhsanov6531]

Очень полезный контент! Спасибо! Было классно если будет продолжение данного видео. Хотелось бы очень капнуть глубже. Все тесты, которые мы сегодня писали являются Unit Tests, правильно я понял ?

[@alexandrsakharov629]

Да, в этот раз только юнит тесты, Сейчас вышло второе видео с интеграционными тестами.

[@tolibdilmurodov1434]

Спасибо очень полезно было.

[@mihaelbablovich9463]

Повезло мне с вашим каналом ❤

[@igyo]

Ждём следующую часть

[@Narimaning]

Там что, GET с телом запроса? 🤔 PS. Спасибо!

[@delay_gryaz_chisto]

полезно. спасибо

[@АртемТимофеев-я1ы]

спасибо большое

[@имяфамилия-х4с9о]

Спасибо

[@mzmzmzmzmq]

что за клавиатура? звук просто офигенный!

[@Rundik]

Как тема называется в вскоде?

[@aegirey4341]

Доброго дня! Почему в валидации стоимость и юзер айди не проверяем на отрицательные значения, а только на ноль?

[@imbalos]

мб потому что это написанный на коленке простой пример?

[@SecretSecret-c7o]

Для user_id, amount использовал uint64, на json.Unmarshal сломается, и вернет ошибку, даже не дойдя до валидации: ```bad json: json: cannot unmarshal number -1 into Go struct field OrderIn.user_id of type uint64```

[@alekseytrump1586]

Тема в vs code какая?

[@emotional_stuff]

кайф

[@Vadyas]

Awesome

[@asmr_codster]

Сложно понять что такое entities :)

[@AlexQA]

Это все интересно конечно)) А как в GO с зарплатами ручников?))

[@emotional_stuff]

каво? какие ручники)

[@developmentapp]

почему вЁб? :)

[@Mur466]

Чем больше я вникаю в тему юнит-тестирования, тем больше убеждаюсь что это хлопотная суета и практически бесполезная. Чтобы в базу мусор не попал нужно констрейны в базе делать. И они гарантируют отсутствие в базе мусора, не только предотвращают в будущем, но и гарантируют, что он не попал туда в прошлом. Ошибок в тестах у вас было на порядок больше чем в коде. И это были настоящие ошибки, а не намеренно допущенные для примера. От реальных багов, то есть не предусмотренных программистом ситуаций, тесты, написанные им же не могут спасти по определению. И только ради тестов нагромождение абстракций, интерфейсов моков. Проект уровня бумажный самолетик превращается боинг по сложности, срокам и цене.

[@antonpy7710]

можете привести пример ошибок в тестах?

[@nikolaykozlov4888]

Саш, у тебя полка книжная сломалась :-)))

[@CatWorldson]

Гошечка, ideшечка,кейсик, табличка, ошибочка, слайсик, idшечка, тестики, юзкейсик. Боже, что с го разрабами не так, объясните плз откуда это пришло)

[@nikitqa6985]

Стоило немножко подготовиться к презентации, диаграмма приведенная из чистой архитектуры представлена очень малым набором признаков. То есть - не понятно что автор имеет ввиду под астрацией бизнес логики и что под абстракцией контроллеров. Entity так вообще не объяснено ничем, кроме как - ну это сущности... Очевидная ошибка логики.

[@bublick346]

А что бы быть golang разработчиком обязательно быть хипстером? Спасибо за видео.

[@genjishimada4308]

11:30 мои глаза люди со светлым стилем IDE, ЗАЧЕМ?!

[@Vadyas]

Чтоб читать лучше было на ютубе, нет? Не у всех какой-нибудь там олед экран. На дешёвых экранах вообще ничего не видно на тёмном фоне

[@SergeyTish]

Когда работаешь в светлой, хорошо освещенной комнате, тогда удобней работать со светлой темой IDE.

[@zeroidandroid]

А тупо так привычнее! И ещё темы меняются под освещение, настроение, тип экрана…

[@Аудиокниги-г8д]

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

[@timickb]

тестик в слайсик

[@Аудиокниги-г8д]

заказик, апишечка, дежйсончик - это московский сленг?

[@artemkas4191]

Ещё интересно, что такое ручка? Неужели это хендлер?

[@Аудиокниги-г8д]

@@artemkas4191 да, это хендлер. Автор не знает нормального названия.

[@OOOJohnJ]

@@Аудиокниги-г8д может и знает. Использование понятия ручка я встречал во многих компаниях, в том числе в Озоне и Яндексе, начал даже считать что все продвинутые компании в России пользуются этим словом. Тогда как более мелкие и простые компании оперируют понятиями endpoint, handler

[@Аудиокниги-г8д]

@@OOOJohnJ это просто показывает безграмотность. Да черт с ней с ручкой, но что за новопи-рский сленг, вроде бы программисты должны быть интеллигенцией, но не могут нормально даже говорить.

[@OOOJohnJ]

@@Аудиокниги-г8д мне кажется больше дело привычки. Мне вот "ручка" тоже ухо режет, хотя постепенно привыкаю. На мой взгляд, если и называть по-русски, то более подходящее слово лучше найти.

[@yarbersheer8559]

Всё конечно классно... Но как pkg попал в internal ??? Со структурой проекта вообще ахтунг какой-то... У папки Internal есть чёткий смысл - она выполняет ещё один вид инкапсуляции в случае если находится внутри вложенного пакета. У меня кровь из глаз... а я джун... не надо так ((( Структура проекта нарушает Standart Layout и вообще не пойми чем обусловлена. Договорились же видеть 3 папки: cmd, internal, pkg. И pkg - общие пакеты, возможные для использования в других проектах... Куда какой тест пихать в такой структуре? Где доменная область, где транспортная, где репо... Убейте меня! А ещё под слоем UseCase обычно есть слой Service, тогда сервис работает с сущностью, а UseCase работает с методами сущностей....

[@SecretSecret-c7o]

Project layout о pkg в internal: Your actual application code can go in the /internal/app directory (e.g., /internal/app/myapp) and the code shared by those apps in the /internal/pkg directory (e.g., /internal/pkg/myprivlib).

[@yarbersheer8559]

@@SecretSecret-c7o именно, Сашенька) code shared for those apps ) но у нас тут нет apps ) папка pkg на одном уровне с cmd - общий код для программ в cmd. А папка pkg в интернал - общий код для програм в интернал ) В данном случае, во-первых, это вообще аццкий лейаут, который я вообще за год никогда не видел, а во-вторых - он не логичный с точки зрения слоёв.

[@yarbersheer8559]

@@SecretSecret-c7o ты бы сам понял в таком наборе папок где какая сущность и сервис? Как они связаны? Как отделены? Смысл вообще не в стандарт лейаут, хотя и он не зря сделан, а в том, что тут вообще логика потеряна. Почему main.go лучше класть в папку вложенную в cmd знаешь? А почему usecase лучше держать на том же уровне, что и app? Когда ты видишь слоистость в уровне и месте вложенности папок, тебе на много проще программировать и любому другому, кто придёт после тебя.

[@Vadyas]

ты же в курсе, что "project standard layout" - не стандартный layout? Даже rsc создал issue в этом репозитории, потому что люди ошибочно считают это каким-то стандартном. Это во-первых. А во-вторых, структура проекта - очень субъективно. Мне кажется, в go сообществе недостаточно *официальных* руководств по наименованию пакетов и оформлению структур проекта, поэтому каждый оформляет как он хочет. Я к тому, что это общая проблема, и пока не будет действий от разработчиков языка, то придётся видеть разные реализации структур. Кмк, спорить на эту тему лишено смысла.

[@Vadyas]

В смысле вы не увидели репо, транспорт и домен? Я не знаю как вы смотрели, но там же прямо написано "repository", "user case" "handlers". Может оно названо чуть по другому, но смысл выполняют тот же. Не верите мне - посмотрите доклад по структуре проекта от evrone.