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

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

Ну смотрите вы код в функции на основании чего выносите?

на основании спеки

на основании спеки

То есть вы весь код в Публичных функциях пишете?

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

почему именно не документированные? может каменты я и напишу для них. Но в принципе сами тесты можно считать документацией иногда

нельзя считать тесты документацией

То есть вы весь код в Публичных функциях пишете?

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

а вот что тестируете вы - я пока не понял

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

Ну вы когда приватную функцию пишете вы же вкладываете в нее какой-то смысл?

нельзя считать тесты документацией

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

Ну вы когда приватную функцию пишете вы же вкладываете в нее какой-то смысл?

при чем тут тесты?

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

потому, что тесты - это не дока

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

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

при чем тут тесты?

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

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

и что я тестировать-то буду?

свои ожидания?

и что я тестировать-то буду?

Что эта функция выполняет ваши ожидания.

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

если спека содержит детали реализации - это говно, а не спека

если спека содержит детали реализации - это говно, а не спека

Если мне только http api опрделено, то мне не тестировать go код. Только внешний интерфейс?

Что эта функция выполняет ваши ожидания.

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

Если мне только http api опрделено, то мне не тестировать go код. Только внешний интерфейс?

для других тестов у вас нет оснований

потому, что тесты - это не дока

пусть будет не дока. Но даёт достаточно представления о коде чтобы его сопровождать и читать. Пойнт в том, что (иногда) нет мне смысла делать нетривиальный код отдельным пакетом и писать на него документацию, поскольку не будет он повторно использоваться. Но какие-то гарантии что он работает - таки хочется иметь

смотрите

самые серьезные ошибки - это неправильно понятая спека

именно с тестирования кода на соответствие спеке и надо начинать

где заканчивать - ваше дело

именно с тестирования кода на соответствие спеке и надо начинать

это да

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

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

для других тестов у вас нет оснований

Отлично. Вашей команде пришло задание на целую систему. Мобильное приложение и бэкенд. По факту у вас есть утвержденный дизайн в спеке и логика. Что тестируем?

с этого места мы не то, что тестировать - мы разрабатывать не можем начать

Можете.

Заказчику все равно какое api у вас там.

сейчас архитектор разрисует нам структуру и напишет спеки на интерфейсы - и можно будет начинать. тесты на соответствие интерфейсам мы напишем на основании этих спек

при чем тут заказчик вообще?

сейчас архитектор разрисует нам структуру и напишет спеки на интерфейсы - и можно будет начинать. тесты на соответствие интерфейсам мы напишем на основании этих спек

Архитектор в вашей команде.

более того - это я сам

и что?

Вы и архитектор и программист. Вы разрисовываете интерфейс и тестируете его?

и что?

Что вы тестируете? свои ожидания от того что вы напроектировали?

документированные ожидания

Эта документация живет только среди вашей команды.

и что?

Я также могу задокуметировать внутреннее устройства пакета. Мало того это и нужно делать.

зачем?!

Просто когда я пишу пакет я и архитектор его и реализатор.

зачем?!

Чтобы когда кто-то в него полез он понимал что происходит.

он и так поймет, не беспокойтесь.

если уж до деталей реализации доберется

Если там нетривиальный код, то с доками проще.

рили?

код я все равно прочту, потому, что дока врет все время

Ну то как вы пишете доки это уже ваш опыт.

Или комменты внутри реализации вы тоже не пишете?

при чем тут комменты? при чем тут дока на детали реализации? вы помните, о чем разговор?

он и так поймет, не беспокойтесь.

понять то поймёт, но с юнит тестами боли меньше кмк

конечно, меньше

безусловно

так почему не стоит писать тесты?

если есть время и желание

стоит, конечно! на все, на что есть спека

при чем тут комменты? при чем тут дока на детали реализации? вы помните, о чем разговор?

Доки в го генерятся из комментов. Коммены я пишу и они почти что дока описывающая что я пишу. И я это тестирую.

хотите тест - напишите спеку сначала

хотите тест - напишите спеку сначала

вот!

хотите тест - напишите спеку сначала

спеку на внутреннюю реализацию? это же говноспека!

ERROR: S client not available

тогда не пишите

но и тестов тогда тоже не надо

т.е. у вас в комманде так, ок

потому, что тесты без спеки - это просто способ убить время

Знаете для заказчика все то что вы как архитектор там наваяли тоже детали реализации.

у вас заказчик юнит-тесты пишет?

Нет конечно.

вы с какой-то простой мыслью спорите

для тестирования нужен эталонный вход и эталонный выход

они должны быть документированы и каким-то образом проверены

Отлично. Для заказчика эталон это кнопку в приложении и получить сообщение на экране.

хотите тест - напишите спеку сначала

да, это бесспорное утверждение. То есть грубо говоря на каждую тестируемую функцию писать осмысленный Го-стайл коммент

Отлично. Для заказчика эталон это кнопку в приложении и получить сообщение на экране.

именно это и будет тестировать заказчик

вообще, конечно, я от этого разговора устал

именно это и будет тестировать заказчик

Ну тогда не имеет смысла тестировать все что внутри.

опилки

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

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

да, это бесспорное утверждение. То есть грубо говоря на каждую тестируемую функцию писать осмысленный Го-стайл коммент

нет, go-style comment это не спека.

подитожим, по сути вы утверждаете что "но обычно заканчивать надо там, где достигнут минимально приемлемый результат", является абсолютом, почему "обычно" превратилось в "всегда", неясно, насчет тестирования публичного АПИ никто не спорит, но вы продолжаете гнуть свою линию

илья, у вас тимлид есть?

да

вот ему этот вопрос и задайте :)

нет, go-style comment это не спека.

А что тогда спека в go для пакета?

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

нет, go-style comment это не спека.

в каком же виде надо писать спеку тогда?

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

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

зависит от задачи. в общем случае - нет

А как он понимает, что надо отменить транзакцию?

а?!

обычно, ели транзакция не прошла успешно - ее надо ролбечить

но штука в том, что транзакция держит коннект к базе