а почему именно нет? :)

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

Просто я подорвался на Go пописывать, кое-что для себя, как продвинутый пользователь. Вот и сижу тут :)

Привет всем. Нормально ли делать такое? type time.Time MyTime // custom method on built-in type alias func (t MyTime) DayBefore() MyTime { // code } Или лучше просто в функцию, принимающую time.Time сделать?

Если ты из типа не делаешь интерфес с его собственными методами, то не стоит. Будет проще использовать тип time.Time в стандартном виде

Если ты из типа не делаешь интерфес с его собственными методами, то не стоит. Будет проще использовать тип time.Time в стандартном виде

ну для удобства можно, или у тебя будет еще 'type time.Time MyTime2' и это совсем разные сущности

Спасибо

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

хотя, 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% это только для истинных ниндзицу, познавших мастерство кунг фу

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

ERROR: S client not available

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

Всем привет помоги со свагерром ставлю на мак ось - не хочет работать ставлю так 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 нет приватных методов. Просто хочешь сделать черный ящик - сделай. И все. Никаких приватных методов нет.

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

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

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

нет, не будет. Конкретнее будет просто не путать Go и плюсы с питоном, в смысле конкретно терминологии и методологи

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

нет никого

никого нет...

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

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

так проблема же

дык, в том и делло!

что за проблема-то?

Можно непростой вопрос? Вот за 1.5 года на python я выяснил почти все его направления использования: data science/web/администрирование/чуть науки. Понятно куда лезть и как. А какие основные направления у golang?

Можно непростой вопрос? Вот за 1.5 года на python я выяснил почти все его направления использования: data science/web/администрирование/чуть науки. Понятно куда лезть и как. А какие основные направления у golang?

велосипеды и выпендреж

но на сервисах и без легаси, что плюс