Товарищи, привет! Кто sqlx юзает? Когда в функции стартуешь транзакцию, надо ли по defer ее роллбечить, если вдруг случится что? Паника, например?

Since transactions are connection state, the Tx object must bind and control a single connection from the pool. A Tx will maintain that single connection for its entire life cycle, releasing it only when Commit() or Rollback() is called. You should take care to call at least one of these, or else the connection will be held until garbage collection.

что происходит с коннектом, когда до транзакции добирается gc - я не в курсе, надо код смотреть.

но, скорее всего, ничего хорошего - деструкторов-то нет

Да, я читал это. Жаль, что в го нет деструкторов( Я просто даже не знаю, как поступить. Если вешать defer, то есть шанс, что паника случится уже после нормального коммита.

а надо разбить код по функциям правильно

чтобы не было такой опасности

или выставлять по комиту флаг, и проверять его в deffer

но первый вариант лучше

обычно именованный возвращаемый параметр + блок // Making sure the tx is closed regardless of the result defer func() { if err != nil { tx.Rollback() return } err = tx.Commit() }()

но первый вариант лучше

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

лучше, когда у вас код правильно структурирован

Я понял, надо делать функцию, которая начинается с begin, а заканчивается коммитом) Тогда любая паника может случится только внутри транзакции (ну или при коммите, если соедниение пропало, но тут уже все равно)?

вообще, конечно, лучше бы панику не ловить.

ну это понятно

но мало-ли что

ваша программа завершится, транзакция откатится по закрытию соединения

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

а если это сервер, который также обрабатывает еще 1000 клиентов, у которых все ок?)

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

ваша программа завершится, транзакция откатится по закрытию соединения

вот я это имел ввиду говоря, что в общем случае явеый роллбэк не нужен

если не ваш - скорее всего, либа, которая панику кинула, продолжать работу не может

Вброшу про тестирование публичных/приватных методов: https://youtu.be/yszygk1cpEc?t=1925

видимо, это тоже опилка ?

думаете?

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

аргументы в пользу какого тезиса у него такие же?

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

ваша позиция не основана ни на чем, кроме ваших же ощущений

и тесты вы такие же пишете - ни на чем не основанные, кроме ваших предположений

и необходимость их написания обосновываете вашими же соображениями о здравом смысле

я спросил - зачем нужны тесты

ответ был единственный: "чтобы ошибка не попала в прод"

3 пункт на слайде, на который дана ссылка "some people take it too far and choose only integration/acceptance tests" - это то, о чем вы говорите

нет

не об этом

integration/acceptance - это не про юнит-тесты вообще

как это - у вас есть спека - это acceptance - то, что волнует заказчика

а вот это - опилки

про заказчика мы поговорили уже

3 пункт на слайде, на который дана ссылка "some people take it too far and choose only integration/acceptance tests" - это то, о чем вы говорите

это вообще не имеет отношение к разработчикам и юнит тестам.

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

скажите - а вы всегда стоите на своем до конца?

когда есть вермя, и спорим явно о цвете фламастеров, почему бы и нет, ваше подход правилен для 70% кода, который я писал, но говорить о том, что это абсолют - странно

абсолют...

если делать правильно

1. пишете спеку на внутреннюю функцию

2. утверждаете ее у тимлида, вносите как-то в доку (как?)

3. пишете в соответствии со спекой тесты

4. отправляете их тимлиду на ревью

5. он тратит примерно 10 минут, чтобы объяснить вам, почему отдельный тест не нужен, все, что надо, покрыто тестами публичной части

6. вы продолжаете стоять на своем

вот это настоящий абсолют, нерушимый

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

вопрос

а есть ли у вас вообще тимлид?

или это тоже опилки?

это кому вопрос?

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

это ответ на это сообщение

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

а кто будет проверять, что спеке всё соответствует? что спека покрыла все случаи? что реализация также покрыла все случаи?

примерно 90% того кода, что я написал, спеки не имели, не имели и тестов, соответственно

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

хорошо, когда имплементишь что-то по RFC - там спека есть

примерно 90% того кода, что я написал, спеки не имели, не имели и тестов, соответственно

ну - мне так писать неудобно

может включать, может не вклюать, зависит от процесса, у нас такого нет

ну - мне так писать неудобно

всем неудобно

ERROR: S client not available

всем неудобно

ну вот. и я просто стараюсь не писать ничего без тестов

примерно 90% того кода, что я написал, спеки не имели, не имели и тестов, соответственно

вы считаете это нормой?

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

это, кстати, неплохая идея, попробую предложить команде

ну вот. и я просто стараюсь не писать ничего без тестов

у нас довольно большой проект, он покрыт тестами на >90% как на бэке, так и на фронте

а так внешние (к сервису) интерфейсы обычно фиксирует qa, я не библиотеку разрабатываю, в этом случае было бы разумнее сразу готовить black box

у нас довольно большой проект, он покрыт тестами на >90% как на бэке, так и на фронте

а где бы почитать/научится про то как делать спецификации и тесты, покрывающие все случаи?

Хотелось бы внедрить, но непонятно с какого конца начать, чтобы в итоге прийти к тестам, а не имитациям тестов.

вы считаете это нормой?

нормой в смысле "так и надо"? нет, не всегда. нормой в смысле "заказчик не оплатил тесты"? да, в этом смысле это норма

это грустно

Хотелось бы внедрить, но непонятно с какого конца начать, чтобы в итоге прийти к тестам, а не имитациям тестов.

начать нужно сначала. почитать о фаззинге. но цель не только определить зависания и/или падения, а и ошибки в спеке

нормой в смысле "так и надо"? нет, не всегда. нормой в смысле "заказчик не оплатил тесты"? да, в этом смысле это норма

а у тебя не уходит больше времени на разработку, когда тестов нет?

начать нужно сначала. почитать о фаззинге. но цель не только определить зависания и/или падения, а и ошибки в спеке

Спасибо.

а у тебя не уходит больше времени на разработку, когда тестов нет?

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

Спасибо.

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

начать нужно сначала. почитать о фаззинге. но цель не только определить зависания и/или падения, а и ошибки в спеке

может зафигачишь доклад на эту тему? или порекомендуешь посмотреть/почитать что то конкретное? Это было бы очень полезно для сообщества ?

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

ну - благо, я с разработкой mvp уже не связываюсь, разве что в своих проектах

может зафигачишь доклад на эту тему? или порекомендуешь посмотреть/почитать что то конкретное? Это было бы очень полезно для сообщества ?

может быть, может быть

ну - благо, я с разработкой mvp уже не связываюсь, разве что в своих проектах

minimal viable product?

minimal viable product?

йеп

работаю в компании, где уже есть mvp, и нужно довести всё до ума

я работал в perl-c монолите без спеки и доки, с test coverage 5%, ? поэтому тема меня эта цепляет, если вы клепаете такие продукты без тестов, кто-то потом их будет саппортить и, чем больше тестов, тем лучше ?

у нас до code review таска не доходит, пока тестов нет. всё просто)

это - хорошая морска практика ?

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

а бесполезные тесты кто-то считает вообще существующими тестами?

если тест бесполезен - его нет

я видел тесты, которые писались только для того, чтобы ci не жаловался на уменьшение coverage

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

ну - я не сомневался, что ты повидал больше, чем я %)

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

если тест бесполезен - его нет

привет) загляни в лс

привет) загляни в лс

привет) ответил, спасибо