MB
Написал 2 бенч-теста, в 1 передаю в функцию структуру через *, в другом передаю без нее (по сути копию).
Запускаю тесты и не вижу разницы, по аллокациям. Я неправильно понимаю как это работает?
Size: a a a
2020 May 02
P
Polkota
Ребята, помогите, не смог разобраться
RS
Polkota
Написал 2 бенч-теста, в 1 передаю в функцию структуру через *, в другом передаю без нее (по сути копию).
Запускаю тесты и не вижу разницы, по аллокациям. Я неправильно понимаю как это работает?
Запускаю тесты и не вижу разницы, по аллокациям. Я неправильно понимаю как это работает?
где код?
s
Вообще вижу в исходниках синкмапы, что она как atomic юзает, но в определенной ситуации откатывается к mutex.
Atomic может выигрывать по скорости.
Atomic может выигрывать по скорости.
Atomic и должен выигрывать. Потому что мьютексы на атомарных операциях cas сделаны
2020 May 03
VI
что можно считать юнит-тестом? простите за глупый вопрос, но сейчас объясню. вот у меня есть некий пакет для работы в базой данных. там куча функций, и я хочу протестировать их все в отдельности. я не пытаюсь замокать монгу, а беру, скажем, dokertest, который автоматом поднимает монгу и убивает после теста. вроде это интеграционный тест, но тестирую я всего одну функцию вне связки с остальными. как это назвать?
DP
все равно - интеграционный
DP
юниты вы могли бы написать, если бы между вашим кодом и монгой создали прокладку упрощенной - только ваши потребности - функциональности, и замокали ее.
вот тогда можно было бы писать юниты
нужно ли это - определяется сложностью логики в том, что вы тестируете.
если там тупой перекладыватель полей - тестировать его отдельно нет смысла, интеграционные тесты вам понадобятся по любому
если там сложная логика - лучше обеспечить ее тестирование отдельно от базы, чтобы не было потом вопросов, где поломалось. интеграционные тесты при этом все равно обязательны
вот тогда можно было бы писать юниты
нужно ли это - определяется сложностью логики в том, что вы тестируете.
если там тупой перекладыватель полей - тестировать его отдельно нет смысла, интеграционные тесты вам понадобятся по любому
если там сложная логика - лучше обеспечить ее тестирование отдельно от базы, чтобы не было потом вопросов, где поломалось. интеграционные тесты при этом все равно обязательны
AK
что можно считать юнит-тестом? простите за глупый вопрос, но сейчас объясню. вот у меня есть некий пакет для работы в базой данных. там куча функций, и я хочу протестировать их все в отдельности. я не пытаюсь замокать монгу, а беру, скажем, dokertest, который автоматом поднимает монгу и убивает после теста. вроде это интеграционный тест, но тестирую я всего одну функцию вне связки с остальными. как это назвать?
Я бы поставил здесь вопрос так: Каким тестированием я здесь занимаюсь? Ответ: Интеграционным. Юнит-тестом в Go можно считать функцию, но в вашем случае, называя его юнит-тестом вы реализовали анти-паттерн: Excessive Setup
AC
Всем привет. Ребят, подскажите пожалуйста. При каких обстоятельствах стоит задумываться о том, что стоит переходить на го? Как я понимаю го используется в основном для создания микросервисов в какой-то сложной архитектуре, где ставятся задачи, с учетом того, что очень большое количество людей будет пользоваться продуктом. Стоит ли его изучать если пока таких целей не ставится? Я думал что го станет отличной заменой избыточной архитектуре фреймворков, которых мы используем и на нем будет удобно писать Restful API. Прав ли я или заблуждаюсь?
DP
вопрос не ясен
DP
на go вам не дадут - пока? - ни рельс, ни спринга. это и достоинство, и недостаток
RE
еще бы интересно понять, а на чем вы сейчас пишете. Вдруг на C++ какой нить HFT делаете. То зачем Вам вообще go? И так денег небось гребете ))