кстати насчёт go test... https://blog.karenuorteva.fi/go-unit-test-setup-and-teardown-db1601a796f2 разве нет возможности задекларировать beforeEach и afterEach нежели самому ручками в каждом кейсе вызывать?

везде вижу только TestSomething(t *testing.T) { setup() defer teardown() //test }

что это такое вообще

Это то без чего твой код превращается в тыкву ?. А вообще внешние зависимости зло - проверенно собственной тощей жопой

кстати насчёт go test... https://blog.karenuorteva.fi/go-unit-test-setup-and-teardown-db1601a796f2 разве нет возможности задекларировать beforeEach и afterEach нежели самому ручками в каждом кейсе вызывать?

Можно, но зачем?

Можно, но зачем?

integration testing

после каждого теста нужно сбросить сессию соединения

не, можно конечно в каждом тесте новый клиент открывать, но это не айс

integration testing

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

у меня сейчас на кастомном ранере, не на go test работают тесты, но я хочу таки перейти снова на стадартный tool chain

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

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

хмм, честно говоря сути не понял) что ты имеешь ввиду конкретно?

в каком смысле "заявляются"

integration test'ы нам нужны чтоб проверять API

хотя наверное правильнее будет называть их "acceptance test"ами

в каком смысле "заявляются"

В смысле: "Пацаны, мы разработали фрэймворк для тестирования контроллеров , написать тест - как два пальца об асфальт и не надо трахать мозг и ломать пальцы", в жизни это выглядит так. Легко накидать тест на очень примитивный кейс, но стоит задуматься о error-рейтах, сообщениях от шедулера а-ля "сейчас допрыгаешься", и все превращается в адскую головоломку.

хотя наверное правильнее будет называть их "acceptance test"ами

Нет, неправильно. acctptance test - результат соответствующий user story.

Извини что наполовину на аглицком, но при переводе могут возникнуть непонятки

Нет, неправильно. acctptance test - результат соответствующий user story.

ну оно так и есть

120-150 нет

excuse me?

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

В смысле: "Пацаны, мы разработали фрэймворк для тестирования контроллеров , написать тест - как два пальца об асфальт и не надо трахать мозг и ломать пальцы", в жизни это выглядит так. Легко накидать тест на очень примитивный кейс, но стоит задуматься о error-рейтах, сообщениях от шедулера а-ля "сейчас допрыгаешься", и все превращается в адскую головоломку.

честно говоря не понимаю о чём ты... у нас есть API, есть ожидаемые данные, делаем запросы на определённые ноды графа, проверяем результаты. просто нужны beforeEach и afterEach функции, которые не понимаю как реализовать на стандартном go test

честно говоря не понимаю о чём ты... у нас есть API, есть ожидаемые данные, делаем запросы на определённые ноды графа, проверяем результаты. просто нужны beforeEach и afterEach функции, которые не понимаю как реализовать на стандартном go test

Ааааа, Семён Сёменыч. Так тест - это тоже программа на Go, как хочешь так и крути. Приведи конкретный кейс.

Ааааа, Семён Сёменыч. Так тест - это тоже программа на Go, как хочешь так и крути. Приведи конкретный кейс.

я ж говорю, у нас сейчас кастомный test runner, который берёт структуру и выполняет все экспортируемые её функции как кейсы, есть специальные зарезервированные названия такие как BeforeAll, AfterAll, BeforeEach и AfterEach

но я размышляю как реализовать тоже самое на go test

Извини, но без кода, я что-то не въезжаю, в чем проблема.

Извини, но без кода, я что-то не въезжаю, в чем проблема.

выполнять функцию перед каждым и после каждого TestSomething в go test, не могу понять как

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

В тестах можно объявлять и глобалы и init. И собственно, обвязать как угодно. Давай, чтобы твою епархию не палить, обвяжем тестами какую нибудь гипотетическую фигню. Ну так чтобы продуктивней, а то что-то трясем воздух, трясем, а до точки что-то недотрясываемся.

В тестах можно объявлять и глобалы и init. И собственно, обвязать как угодно. Давай, чтобы твою епархию не палить, обвяжем тестами какую нибудь гипотетическую фигню. Ну так чтобы продуктивней, а то что-то трясем воздух, трясем, а до точки что-то недотрясываемся.

дак придётся ручками вызывать

если в стандартной go test не возможности автоматически выполнять до/после то мы лучше оставим на кастомном ранере

дак придётся ручками вызывать

Да, прийдется. А еще потом можно ручками отбенчить, выявить "бутылочное горлышко", найти того кто его написал, и попросить его быть поаккуратней. Иначе зачем выбирать Go?

Да, прийдется. А еще потом можно ручками отбенчить, выявить "бутылочное горлышко", найти того кто его написал, и попросить его быть поаккуратней. Иначе зачем выбирать Go?

а чем тогда наш test runner хуже go test?

а чем тогда наш test runner хуже go test?

Гибгостью наверное. Но посмею предположить, что в Go вы пришли не из C/C++, а из более высокоуровневых языков. Нет, это никак вас не умаляет, просто надо немного сменить привычки. Писал когда ты запостил скриншот. Разреши "доебаццо" :). Какой из этих тестов показал степень устойчивости? А на фаззинг? А на предполагаемые трики?

Гибгостью наверное. Но посмею предположить, что в Go вы пришли не из C/C++, а из более высокоуровневых языков. Нет, это никак вас не умаляет, просто надо немного сменить привычки. Писал когда ты запостил скриншот. Разреши "доебаццо" :). Какой из этих тестов показал степень устойчивости? А на фаззинг? А на предполагаемые трики?

я FullStack, в чём я уже только не работал, PHP, C++, JavaScript, теперь Go

я FullStack, в чём я уже только не работал, PHP, C++, JavaScript, теперь Go

Фулстэк подразумевает фронтенд+бэкенд))

Почти то-же самое,

Фулстэк подразумевает фронтенд+бэкенд))

yep, I know, фронт на JavaScript/C++ и на Go/C++/PHP/JS на бэке

Добрейший вечерочек! Помогите пожалуйста. Нужно ли создавать демона, чтобы запускать go исполняемый файл в фоне? Или можно просто запустить исполняемый файл и ждать пока выполнится? Если создать демона то как? Мне нужно запустить программу на сервере, чтобы она отработала в фоне с логами.

Фулстэк подразумевает фронтенд+бэкенд))

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

Добрейший вечерочек! Помогите пожалуйста. Нужно ли создавать демона, чтобы запускать go исполняемый файл в фоне? Или можно просто запустить исполняемый файл и ждать пока выполнится? Если создать демона то как? Мне нужно запустить программу на сервере, чтобы она отработала в фоне с логами.

Зачем тебе демон?

Зачем тебе демон?

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

Я хочу запустить скрипт и отключиться от сервера

от ssh

Добрейший вечерочек! Помогите пожалуйста. Нужно ли создавать демона, чтобы запускать go исполняемый файл в фоне? Или можно просто запустить исполняемый файл и ждать пока выполнится? Если создать демона то как? Мне нужно запустить программу на сервере, чтобы она отработала в фоне с логами.

Я так делаю func main() { for { //тут код } } Далее это безобразие запускается через системд.

Гибгостью наверное. Но посмею предположить, что в Go вы пришли не из C/C++, а из более высокоуровневых языков. Нет, это никак вас не умаляет, просто надо немного сменить привычки. Писал когда ты запостил скриншот. Разреши "доебаццо" :). Какой из этих тестов показал степень устойчивости? А на фаззинг? А на предполагаемые трики?

единственное что приходит в голову что скорее всего с кастомным ранером не будет работать это coverage profile

Я хочу запустить скрипт и отключиться от сервера

мона так nohup ./app &

Я так делаю func main() { for { //тут код } } Далее это безобразие запускается через системд.

У меня есть скрипт который что то делает. Он после конечно сам выполнится и завершится. Просто мне надо его один раз запустить и спокойно скормить серверу на обработку и заняться другими делами отключившись от сервака

мона так nohup ./app &

Попробую Мне чот такое советовали

А что с логированием? Как ту можно реализовать?

Через сторонние библиотеки или запись в файл?

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

На заборе тоже много чего пишут..., а там дрова. В каком фоне? Что фактически нужно сделать?

На заборе тоже много чего пишут..., а там дрова. В каком фоне? Что фактически нужно сделать?

Подсоединиться к ssh. Запустить скрипт. Отсоединиться. Иногда буду подключаться и проверять все логи в файле.

А что с логированием? Как ту можно реализовать?

Лехко. Читайте в гугле есть.

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

nohup ./your_command &

Лехко. Читайте в гугле есть.

так вот думаю библиотеки или можно сделать простой вывод в лог-файл. Как лучше?

так вот думаю библиотеки или можно сделать простой вывод в лог-файл. Как лучше?

https://golang.org/pkg/log/

нохап будет стдаут и стдерр в файл писать

https://golang.org/pkg/log/

Инициализировать файл и после передать поток байтов в New?

единственное что приходит в голову что скорее всего с кастомным ранером не будет работать это coverage profile

Как-то ты косто мыслишь. Если хоть один метод из тестов не отработал, значит у тебя нет никакого coverage-profile - задача не реализована. Есть возможность дослоцировать обломанный тест и найти человека ответственного за этот код, в чем проблема? Не это не риторический вопрос, я просто пытаюсь понять какую модель тестирования вы у себя замутили

нохап будет стдаут и стдерр в файл писать

Тогда проблем нет. Всем спасибо!

Как-то ты косто мыслишь. Если хоть один метод из тестов не отработал, значит у тебя нет никакого coverage-profile - задача не реализована. Есть возможность дослоцировать обломанный тест и найти человека ответственного за этот код, в чем проблема? Не это не риторический вопрос, я просто пытаюсь понять какую модель тестирования вы у себя замутили

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

Как-то ты косто мыслишь. Если хоть один метод из тестов не отработал, значит у тебя нет никакого coverage-profile - задача не реализована. Есть возможность дослоцировать обломанный тест и найти человека ответственного за этот код, в чем проблема? Не это не риторический вопрос, я просто пытаюсь понять какую модель тестирования вы у себя замутили

acceptance API testing

ERROR: S client not available

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

go coverage ?

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

Если функция объявлена и не покрыта тестами - то coverage её покажет, если тесты написаны паршиво - ну тут вам никто не поможет

Кто имеет пример кода с функциями для базы данных postgresql , удалять элементы, добавлять, зчитувать и тп и как подключатса к ней не локально?

acceptance API testing

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

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

тестируется не robustness, а правильность API

Кто имеет пример кода с функциями для базы данных postgresql , удалять элементы, добавлять, зчитувать и тп и как подключатса к ней не локально?

Читайте мануалы. Там прямо в пакетах примеры

тестируется не robustness, а правильность API

Так, в чем проблема? Создаешь в тесте клиента, и последовательно дергаешь API, вот реально в чем проблема?

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

Так, в чем проблема? Создаешь в тесте клиента, и последовательно дергаешь API, вот реально в чем проблема?

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

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

сделай милдварь для теста, перед выполнением делай setup, после - teardown

сделай милдварь для теста, перед выполнением делай setup, после - teardown

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

хотя, нужно начать с другого вопроса: что даёт go test чего не даст кастомный ранер?

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

Что значит невозможно? <Something_test> - это обычная программа на Go. Равносильно как бы написать клиента к своему же серверу, просто она вызывается на go test. И все, никаких DSL и хитрожопых регекспов, пишешь клиента к своему же API и тестируешься. Не надо ничего усложнять.

Что значит невозможно? <Something_test> - это обычная программа на Go. Равносильно как бы написать клиента к своему же серверу, просто она вызывается на go test. И все, никаких DSL и хитрожопых регекспов, пишешь клиента к своему же API и тестируешься. Не надо ничего усложнять.

ты не понял, имеется ввиду beforeEach и afterEach без дёргания сиих ручкамни

хотя, нужно начать с другого вопроса: что даёт go test чего не даст кастомный ранер?

Рома, постарайся абстрагироваться, то что написано в бэке - это сервер сайд. Тесты - клиент-сайд. Всё.

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

https://goplay.space/#Xez6WkvUeLE

Рома, постарайся абстрагироваться, то что написано в бэке - это сервер сайд. Тесты - клиент-сайд. Всё.

и что ты этим хочешь сказать?))

ты не понял, имеется ввиду beforeEach и afterEach без дёргания сиих ручкамни

Да забудь ты эти рельсы.

https://goplay.space/#Xez6WkvUeLE

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

хотя, нужно начать с другого вопроса: что даёт go test чего не даст кастомный ранер?

Извините, но это похоже на NIH Syndrome. Вопрос надо ставить наоборот

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

https://goplay.space/#1QZWk9SefnG но я не проверял, возможны очепятки

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

вот рабочий https://goplay.space/#qFrge2FetMM

Извините, но это похоже на NIH Syndrome. Вопрос надо ставить наоборот

наоборот он уже был поставлен из чего и родилась идея написать кастомный ранер нам было интересно наблюдать колво assertion'ов и декларативно писать func AfterEach() без сложностей поэтому теперь вопрос задаётся именно так: что go test даёт что не даёт наш ранер

Если вам BDD более близок, то я думаю нет смысла спорить. Вопросы предпочтения конкретной команды/человека

ginkgo правда уже есть

наоборот он уже был поставлен из чего и родилась идея написать кастомный ранер нам было интересно наблюдать колво assertion'ов и декларативно писать func AfterEach() без сложностей поэтому теперь вопрос задаётся именно так: что go test даёт что не даёт наш ранер

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

хотя, нужно начать с другого вопроса: что даёт go test чего не даст кастомный ранер?

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

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

насколько я понимаю что-то вроде https://onsi.github.io/ginkgo/#extracting-common-setup-beforeeach

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

я уже писал выше

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

я ж говорю, у нас сейчас кастомный test runner, который берёт структуру и выполняет все экспортируемые её функции как кейсы, есть специальные зарезервированные названия такие как BeforeAll, AfterAll, BeforeEach и AfterEach

right here

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

так вот именно это меня и интересует, какие именно фичи)