Спасибо

наверное, нет так выразился про сущности)

хотя, func (t MyTime) DayBefore() MyTime это вполне себе метод. Но заключается в том, что `return time.Duration(84_килосекунды) * time.Second

Есть ли смысл огород городить?

почему тогда именно в гочате)?

Вот до таких размышлений UNIX пользователей доводит. Это не продвинутый пользователь винды тебе! :)

Вот до таких размышлений UNIX пользователей доводит. Это не продвинутый пользователь винды тебе! :)

я ща на го под винду пишу((

ужос кокой!

Есть ли смысл огород городить?

сахар всегда вкусный)

не всегда :(

кто пользуется gb, вы делаете мейкфейл чтобы этот гб поставить?

да

да

можно глянуть?

под рукой нет, давно gb не пользую

можно глянуть?

но суть простая go_dep := $(go_path)/bin/dep $(go_dep): $(go_path) go get -u github.com/golang/dep/cmd/dep

меняешь на gb :) и вот собранный gb у тебя будет

День добрый. Пытаюсь тестировать приложение, структура приложения такая: - src - tests Соответственно пакет main и пакет tests, в тестах пытаюсь импортировать main но получаю ошибку import "../src" is a program, not an importable package Есть ли какой-то способ не совмещать файлы тестов и самой программы? Либо каким образом можно в тесты прокинуть структуры и функции из main?

но суть простая go_dep := $(go_path)/bin/dep $(go_dep): $(go_path) go get -u github.com/golang/dep/cmd/dep

ну просто я сделаю вот сначала go get github.com/constabulary/gb/... потом мне надо будет его собрать и бинарь кинуть куда то в /usr/bin там или что-то вроде этого

так?

если ты про ci - то в go_path/bin собираешь и его в path добавляешь

День добрый. Пытаюсь тестировать приложение, структура приложения такая: - src - tests Соответственно пакет main и пакет tests, в тестах пытаюсь импортировать main но получаю ошибку import "../src" is a program, not an importable package Есть ли какой-то способ не совмещать файлы тестов и самой программы? Либо каким образом можно в тесты прокинуть структуры и функции из main?

Не писать в мейне ничего, что не относится к запуску

хотя и не про ci аналогичный совет

если ты про ci - то в go_path/bin собираешь и его в path добавляешь

ну я просто хочу чтобы можно было сделать make install и ничего предварительно не ставить

Не писать в мейне ничего, что не относится к запуску

это как? вынести все из main package?

это как? вынести все из main package?

https://github.com/golang-standards/project-layout

https://github.com/golang-standards/project-layout

кажись понял, а как тогда тестить сам main.go, интеграционные тесты например?

кажись понял, а как тогда тестить сам main.go, интеграционные тесты например?

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

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

Офк нет, в папке тест что угодно может лежать, что тестит

Но остальное так

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

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

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

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

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

и микросервисы которые не торчат наружу тоже не надо?

Микросерисы - это не юнит-тесты

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

Я пропустил возможно, но почему не надо ?

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

зависит от того что написано.. но я бы и приватные проверял, в них тоже баг может запрятаться

Я пропустил возможно, но почему не надо ?

Потому что юниты должны покрывать интерфейс а не детали реализации. Единственное о чем можно парится это о степени покрытия.

Потому что юниты должны покрывать интерфейс а не детали реализации. Единственное о чем можно парится это о степени покрытия.

юнит тесты вообще-то должны дать вам уверенность в том, что написанный код функционирует корректно. Добиться этого можно только 100% (в идеале) покрытием тестами. Если некоторые внутренние функции по какой-либо причине не покрываются тестами экспортированных функций, вы по прежнему уверены что код корректен?

100% покрытие тестами это то ещё дерьмо...

Потому что юниты должны покрывать интерфейс а не детали реализации. Единственное о чем можно парится это о степени покрытия.

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

Так или иначе есть код, который использует приватные функции. С их помощью и можно добиться 100% покрытия

да, прям очень важно покрыть тестами кусок кода if err != nil { panic(err) }

без этого никогда не будешь уверенным

юнит тесты вообще-то должны дать вам уверенность в том, что написанный код функционирует корректно. Добиться этого можно только 100% (в идеале) покрытием тестами. Если некоторые внутренние функции по какой-либо причине не покрываются тестами экспортированных функций, вы по прежнему уверены что код корректен?

Ну чушь же. Для начала - в тестах тоже есть ошибки

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

Ну чушь же. Для начала - в тестах тоже есть ошибки

это уже утверждение на тему "who tests the unit tests?". Начинать надо с того, что тесты должны быть максимально простыми, дабы в них не допускать ошибок. Если спонтанно взять числа с потолка основываясь на интуиции то у меня где-то 50% вероятность допущения ошибки в коде и 5-10% в тесте

Ясно. В го по видимому свои правила покрытия приватных и публичных функций. Хотелось бы посмотреть как вы пишите тесты для Java или php. Через рефлексию?

В go те же правила, что везде

100% покрытие тестами это то ещё дерьмо...

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

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

100% покрытие тестами это не идеал

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

да, кстати

100% покрытие тестами это не идеал

0% покрытия тестами это идеал)

и к нему надо стремиться))))

да, кстати

Вы же в курсе что есть «ожидаемое поведение»?

а вы протестировали свои тесты?

а вы уже осознали бесполезность тестов?

0% покрытия тестами это идеал)

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

Как можно пропустить такой кейс если полностью в тесте контролируется выполнение?

а вы уже осознали бесполезность тестов?

да, настолько что добровольно трачу время на тщательное тестирование. Они настолько бесполезны что неоднократно спасли мне жопу в жизни))

В том числе поведение приватных функций.

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

я надеюсь это сарказм

В го тестирование это чёрный ящик, данные на входе и результат на выходе, в большинстве случаев. Где тут контролируемое выполнение ?

Всем привет помоги со свагерром ставлю на мак ось - не хочет работать ставлю так brew cask install homebrew/cask-versions/java8 brew install swagger-codegen далее пытаюсь выполнить команду swagger-codegen generate server -f example.yaml -t test и получаю Exception in thread "main" io.airlift.airline.ParseArgumentsUnexpectedException: Found unexpected parameters: [server, -f, example.yaml] at io.airlift.airline.Cli.validate(Cli.java:148) at io.airlift.airline.Cli.parse(Cli.java:116) at io.airlift.airline.Cli.parse(Cli.java:97) at io.swagger.codegen.SwaggerCodegen.main(SwaggerCodegen.java:35)

В го тестирование это чёрный ящик, данные на входе и результат на выходе, в большинстве случаев. Где тут контролируемое выполнение ?

причём тут Go вообще? тестирование оно и в Африке тестирование

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

В го я не ощущаю контроля над выполняем теста, что можно опускать тестирование приватных методов

В го я не ощущаю контроля над выполняем теста, что можно опускать тестирование приватных методов

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

а вы протестировали свои тесты?

+100%

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

Сходу только пример про суммирование ошибок в корректный результат

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

если. если. если.

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

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

главное, чтобы тестировщик этого кода не писал, а только тестировал! Чтобы думал не как "писатель"

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

нужны и тестировщики и автоматизированные acceptence тесты и unit тесты и CI. Вопрос лишь в желании быть уверенным в своём коде

нужны и тестировщики и автоматизированные acceptence тесты и unit тесты и CI. Вопрос лишь в желании быть уверенным в своём коде

да

В го я не ощущаю контроля над выполняем теста, что можно опускать тестирование приватных методов

тестирование приватных методов?

Здрасьте :3 Кто-нибудь занимался стримингом видео по сети? (типа как сервисы для просмотра сериалов в онлайн) Я в этом ничего не понимаю, гугление трудно по этой теме, хотелось бы поспрашивать знающих

я

В Go нет приватных методов. Просто хочешь сделать черный ящик - сделай. И все. Никаких приватных методов нет.

со свагерром не работаете?

мы?

В Go нет приватных методов. Просто хочешь сделать черный ящик - сделай. И все. Никаких приватных методов нет.

Неэкспортируемые будет корректнее?