чтобы 1. импортнуть пакет, там не много моно огрести, но есть 2. тестить только то, что экспортится

1. например? 2. как минимум очень спорно

чтобы 1. импортнуть пакет, там не много моно огрести, но есть 2. тестить только то, что экспортится

1. - тоже не понял 2 - одно другому не мешает кмк

1. конфликт имен 2. аминь

1. конфликт имен 2. аминь

можете пример конфдикта имён привести?

можно назвать свой пакет http

можно назвать свой пакет http

и каким образом получится конфликт? import "http" import "custom_name/http"

Одно и тоже имя

сделайте вторую строчку такую import httpcus "custom_name/http"

Одно и тоже имя

ну и пусть одно и то же имя, путь то разный

сделайте вторую строчку такую import httpcus "custom_name/http"

это ошибка компиляции вроде, если импорты имеют одинаковые имена

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

Нет как раз. Ошибкой будет если имена пакетов одинаковые. К примеру пакет http имеет заголовок package http. И если пакет custom_name/http тоже будет иметь в заголовке package http тогда ошибка возникнет а если будет другой заголовок тогда ошибка не возникнет.

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

https://play.golang.org/p/wce9VfGGwG7

Нет как раз. Ошибкой будет если имена пакетов одинаковые. К примеру пакет http имеет заголовок package http. И если пакет custom_name/http тоже будет иметь в заголовке package http тогда ошибка возникнет а если будет другой заголовок тогда ошибка не возникнет.

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

можно назвать свой пакет http

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

Нет как раз. Ошибкой будет если имена пакетов одинаковые. К примеру пакет http имеет заголовок package http. И если пакет custom_name/http тоже будет иметь в заголовке package http тогда ошибка возникнет а если будет другой заголовок тогда ошибка не возникнет.

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

у меня нет идей

еще один неприятный залет - это когда имя в инструкции package и последний элемент пути - разные. тоже без теста с import не выяснишь

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

а, я наверное спросил не правлильно. Надо было - можете привести пример конфликта имён который возник из-за того, что тесты и продакшен код находятся в одном пакете?

еще один неприятный залет - это когда имя в инструкции package и последний элемент пути - разные. тоже без теста с import не выяснишь

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

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

Кстати, в Го не придумали еще как общие хелперы для тестов иметь? Скажем тесты для пакета разделены на два файла, куда всякое общее барахло девать?

Кстати, в Го не придумали еще как общие хелперы для тестов иметь? Скажем тесты для пакета разделены на два файла, куда всякое общее барахло девать?

я стараюсь делать все через интерфейсы и DI и тестирую соответственно через моки к этим интерфейсам, поэтому общего кода между тестами для разных файлов у меня почти нет весь необходимый миниум мне дают пакеты https://github.com/stretchr/testify https://github.com/vektra/mockery

хороший сахар для setup teardown есть в подпакете github.com/stretchr/testify/suite

писать тесты в другом пакете? и зачем?

Приватные функции не тестят. Если тебе нужно ещё написать клиент к этому - получится каша.

почему не тестят приватные функции? ?

тестят только внешний интерфейс, а не детали реализации

тестят то, чем будут пользоваться

странно это, я тестирую то, что хочу протестировать, оно может быть публичным или нет, если есть публичный враппер, который json ами плюётся, а есть внутренняя функция, который struct для json а готовит, я тестирую ее, а не внешний враппер, тк это удобнее.

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

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

но есть еще методология

и методология говорит нам - тестить надо внешний интерфейс

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

здравый смысл

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

Это ж два разных вида тестирований - ты говоришь про интеграционное

не-не-не

это все те же юнит-тесты

А юнит-тесты вполне можно к внутренней части программы применять, не?

Но тестируя внутренние функции ты тратишь время - реализация может меняться

так здравый смысл или методология, или "стандарт индустрии"?

методология

методология

а какое название у этой методологии?)

TDD

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

тдд - о том, что начинаешь с написание теста

да

где там про публичность?

а тест пишешь в соответствии с ТЗ

https://en.wikipedia.org/wiki/Black-box_testing

в ТЗ нет ничего про детали реализации - соответственно, и тест на них написать невозможно

аминь

бюлк бокс - уже ближе к делу, и это одна из методик, там не про юниты, а про интеграционные тесты

бюлк бокс - уже ближе к делу, и это одна из методик, там не про юниты, а про интеграционные тесты

хоть бы прочитал

хоть бы прочитал

не прав, почитал

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

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

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

каждый вправе сходить с ума как ему захочется

коллеги

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

*был не прав

всем привет! один из парметров вызова функции это структура с URL и AcceessTocken, собственно вопрос, а потестировать такую функцию - сейчас она валится из-за неверного AT

а как ты ее потестируешь без сервера

всем привет! один из парметров вызова функции это структура с URL и AcceessTocken, собственно вопрос, а потестировать такую функцию - сейчас она валится из-за неверного AT

- рефакторить, подмокать то место, где проверяется AT, или monkey patching

а как ты ее потестируешь без сервера

httptest.NewServer() сгодится?

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

еще раз - исходя из каких соображений вы пишете тесты на внутренние функции? экспортируемые понятно - их вход и выход прописаны в спеке. а внутренние? сами выдумываете? а смысл?

есть какие-то особенности текущей реализации, о которых внешний контракт не знает, и знать не должен, их тоже, иногда, стоит протестировать

ERROR: S client not available

зачем?

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

еще раз - исходя из каких соображений вы пишете тесты на внутренние функции? экспортируемые понятно - их вход и выход прописаны в спеке. а внутренние? сами выдумываете? а смысл?

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

++

еще раз - исходя из каких соображений вы пишете тесты на внутренние функции? экспортируемые понятно - их вход и выход прописаны в спеке. а внутренние? сами выдумываете? а смысл?

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

нет спеки - нет тестов

вы как дети, ей-богу

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

нет спеки - нет тестов

ага, ты еще скажи "нет ТЗ - нет сервиса"

может просто нечем заняться и let's go writing godlike functions)

что вы тестировать-то собираетесь без спеки? "неужели я молодец?!" - "да, я молодец!"

ага, ты еще скажи "нет ТЗ - нет сервиса"

нет тз - и результат хз

что вы тестировать-то собираетесь без спеки? "неужели я молодец?!" - "да, я молодец!"

С точки зрения спеки там вообще http api на сервисе, но в коде там разделение на пакеты, может только api и тестировать?

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

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

марти макфлай прямо)

дорогая редакция, я худею

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

давайте тогда с начала начнем

зачем вы пишете тесты, тратите на них время и деньги?

зачем вы пишете тесты, тратите на них время и деньги?

Чтобы найти ошибки до попадания в продакшн.

а?!

а как тесты помогают находить ошибки?

ТДД же, пишешь тест, пишешь реализацию

а как тесты помогают находить ошибки?

Они ожидают результат и сверяют его.

а откуда берется эталон, с которым сверять?

От того чего я хочу от этого кода.

а в сам код вы их отчего не заложили?

напоминаю про ТДД

не прав, почитал

This method of test can be applied virtually to every level of software testing: unit, integration, system and acceptance

а в сам код вы их отчего не заложили?

Я не один его пишу.

всё интереснее...

This method of test can be applied virtually to every level of software testing: unit, integration, system and acceptance

* был не прав* поправился ниже :S в смысле хотел написать "был не прав"