Программирование[11]

Просто по идее можно написать тест который будет запускать со слипом каждый помеченный как потенциально опасный метод в параллель к тестируемому. Должно дать какие гарантии и можно автоматизировать, не?

  Arzanis написал 04.06.2024 в 10:55:

Просто по идее можно написать тест который будет запускать со слипом каждый помеченный как потенциально опасный метод в параллель к тестируемому. Должно дать какие гарантии и можно автоматизировать, не?

Не совсем. Слипами и прочим ты тестируешь совокупность имплементации и кейсов которые ты не знаешь. А должен тестировать кейс которые ты знаешь.

До ребяток никак не доходит, что предметом тестирования становится не имлпементация того как у тебя там джейсон перекладывается, а логика синхронизации. Логика работы с примитивами и собственно с тем что представляет из себя сущность полезного кода. От того и не понимания и перлы про "хахаха тестишь имплементацию".

Для этого достаточно и нужно мокать и абстрагировать. Тебе нужно придумать логику работы, и проверить то что ты эту логику заимплементил как ожидалось. Это и является предметом теста.

Тоесть в простейшем примере если у тебя есть метод exec_and_cache Тебе бы неплохо проверить что при вызове его происходит:

connection.lock

connection.exec

connection.unlock

cache.lock

cache.save

cache.unlock

И ни один другой метод не вызывается. Ты ведь продумал логику свою, логику в код транслировал, вот ее и проверяй. Проверяй что два лока в дедлок не могут принципиально встать. Вдруг ты подумал, но накодил cache.lock->connection.unlock?

Скорее проблема непонимания у дуита и ко в том, что они мокинг воспринимают исключительно как способ подсунуть классик без имплементации. Ну чтоб без коннекта в базе как-то запустился. О настоящем тесте асинхронку, таймеров, работы с сокетами, файловой системой, для того что бы проверить как работает то что ты накодил, они не слышали. Просто тестят что у них сокет читается, ну и ладно.

Прописываю чтения документации о пусть будет gmock.

Впрочем я их понимаю, нахуй надо. Это все слишком сложно получается в итоге.

  Grohuf написал 04.06.2024 в 10:03:

По факту уже все сказано. Если ты не понял его доводы, то чем я могу помочь? У каждого есть свой предел.

Чтож, видимо мышления дуита это твой предел. Невысокий оказался.

  Arzanis написал 04.06.2024 в 10:55:

Просто по идее можно написать тест который будет запускать со слипом каждый помеченный как потенциально опасный метод в параллель к тестируемому. Должно дать какие гарантии и можно автоматизировать, не?

Ты не знаешь, где надо поставить слип, пока не видишь баг/крэш.

Пример хитровыебанного бага:

Class A : ThreadSafeRefcounted<A> {
// тут что-то
};

A::A() {
  PostTaskOnWorkerThread(this, &A::SomeMethod);
}
  
main() {
  auto a = MakeRefCounted<A>();
}

Класс A - с подсчетом ссылок. Когда он создается, он не выставляет счетчик ссылок в единицу, потому что всегда он присваивается умному указателю, который инкрементирует этот счетчик на единицу.

Однако в данном случае PostTaskOnWorkerThread тоже будет инкрементировать счетчик на единицу, чтобы объект жил, пока выполняется таска на другом треде. Когда таска выполнится - счетчик уменьшится. Так вот, если задача выполнится до окончания конструктора (что маловероятно, но может быть), то PostTaskOnWorkerThread уменьшит счетчик на единицу, счетчик станет равным нулю и объект удалится на другом потоке (несмотря на то, что конструктор еще не закончился). Когда умный указатель будет инкрементировать счетчик, он это будет делать у мертвого объекта (крэша скорее всего не будет в этом месте, но будет потом).

Чтобы воспроизвести этот крэш, надо поставить слип после PostTaskOnWorkerThread.

  GoldRobot написал 04.06.2024 в 11:37:

Тоесть в простейшем примере если у тебя есть метод exec_and_cache Тебе бы неплохо проверить что при вызове его происходит:

connection.lock

connection.exec

connection.unlock

cache.lock

cache.save

cache.unlock

Показать больше  

Наитупейший и бесполезнейший вариант тестов, которые у нас бывают пишут на "отъебись", чтобы не спрашивали "а почему нет тестов?"

  Grohuf написал 04.06.2024 в 11:47:

  Arzanis написал 04.06.2024 в 10:55:

Просто по идее можно написать тест который будет запускать со слипом каждый помеченный как потенциально опасный метод в параллель к тестируемому. Должно дать какие гарантии и можно автоматизировать, не?

Ты не знаешь, где надо поставить слип, пока не видишь баг/крэш.

Пример хитровыебанного бага:

Class A : ThreadSafeRefcounted<A> {
// тут что-то
};

A::A() {
  PostTaskOnWorkerThread(this, &A::SomeMethod);
}
  
main() {
  auto a = MakeRefCounted<A>();
}

Класс A - с подсчетом ссылок. Когда он создается, он не выставляет счетчик ссылок в единицу, потому что всегда он присваивается умному указателю, который инкрементирует этот счетчик на единицу.

Однако в данном случае PostTaskOnWorkerThread тоже будет инкрементировать счетчик на единицу, чтобы объект жил, пока выполняется таска на другом треде. Когда таска выполнится - счетчик уменьшится. Так вот, если задача выполнится до окончания конструктора (что маловероятно, но может быть), то PostTaskOnWorkerThread уменьшит счетчик на единицу, счетчик станет равным нулю и объект удалится на другом потоке (несмотря на то, что конструктор еще не закончился). Когда умный указатель будет инкрементировать счетчик, он это будет делать у мертвого объекта (крэша скорее всего не будет в этом месте, но будет потом).

Чтобы воспроизвести этот крэш, надо поставить слип после PostTaskOnWorkerThread.

  GoldRobot написал 04.06.2024 в 11:37:

Тоесть в простейшем примере если у тебя есть метод exec_and_cache Тебе бы неплохо проверить что при вызове его происходит:

connection.lock

connection.exec

connection.unlock

cache.lock

cache.save

cache.unlock

Наитупейший и бесполезнейший вариант тестов, которые у нас бывают пишут на "отъебись", чтобы не спрашивали "а почему нет тестов?"

 

Показать больше  

дядь, ты не понял

  Olololnet написал 04.06.2024 в 12:35:

удаление объекта до завершения конструктора - интересная экзотика, в голову просто так не придёт

Есть много причин, почему нельзя писать сложный код в конструкторе и вместо этого использовать методы Init(). Хотелось бы настучать Страуструпу по ебалу за гениально спроектированный язык.

Ты провисшие ссылки то как собрался тестить? 

Еще рофл конечно такую хуйню в конструкторе писать. Конечно придется код написать так что бы он тестировался, а ты как думал?

Хотелось бы послушать как ты покрываешь тестами на протухсшие ссылки/указатели синхронный код. И в чем тут будет разница.

БТВ

Ты вообще какую-то аддовую хуйню написал. Если ты не передал туда владение, просто по this передал, то схуяли оно там должно декрементить и что-то удалять? Тоесть у тебя ThreadSafeRefcounted полагается что кто-то ИЗВНЕ зовет decrease_count или типа того?

  Цитата

Когда умный указатель будет инкрементировать счетчик, он это будет делать у мертвого объекта (крэша скорее всего не будет в этом месте, но будет потом).

На момент вызова ThreadSafeRefcounted счетчик УЖЕ инкрементирован. Его конструктор уже отработал. unless ты отнаследующейся пометив public, и у тебя MakeRef ответственна за инкрементит.

Тогда это уже нихуя не умный указатель.

Не пишите такую хуету как грохуф, прошу вас и заклинаю, изайте шаред птры из стд.

  GoldRobot написал 04.06.2024 в 12:52:

Не пишите такую хуету как грохуф, прошу вас и заклинаю, изайте шаред птры из стд.

Это писал не я, а чел из гугла. Я просто это фиксил (апстримил, офк).

Ты еще не знаешь проблем шаредптра...совсем плох. А такие умные указатели (в бусте они называются intrusive) используются далеко не только в Chromium. Например, в свое время в COMе было сделано именно так.

  GoldRobot написал 04.06.2024 в 12:52:

Ты провисшие ссылки то как собрался тестить?

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

  GoldRobot написал 04.06.2024 в 12:52:

Конечно придется код написать так что бы он тестировался, а ты как думал?

Ты про свои гениальные тесты вида:

MyClass::MyFunc() {
  member_variable_ = 1;
}

MyTest() {
  MyClass tested_class;
  tested_class.MyFunc();
  assert(tested_class.member_variable_ == 1);
}

?

Да, очень полезные тесты. Согласен. Пишешь код в классе, а потом пишешь в тесте проверку, что все операции в функции действительно выполнились.

  GoldRobot написал 04.06.2024 в 12:52:

БТВ

Ты вообще какую-то аддовую хуйню написал. Если ты не передал туда владение, просто по this передал, то схуяли оно там должно декрементить и что-то удалять? Тоесть у тебя ThreadSafeRefcounted полагается что кто-то ИЗВНЕ зовет decrease_count или типа того?

Я просто опустил шаблонную магию, чтобы было легче читать. Так-то понятно, что будет создан шаблоном код, который вызывает this->AddRef().

  GoldRobot написал 04.06.2024 в 12:52:

На момент вызова ThreadSafeRefcounted счетчик УЖЕ инкрементирован. Его конструктор уже отработал. unless ты отнаследующейся пометив public, и у тебя MakeRef ответственна за инкрементит.

Тогда это уже нихуя не умный указатель.

Я вроде все расписал, а ты все равно не понял.

  Grohuf написал 04.06.2024 в 13:19:

 

  GoldRobot написал 04.06.2024 в 12:52:

Конечно придется код написать так что бы он тестировался, а ты как думал?

Ты про свои гениальные тесты вида:

MyClass::MyFunc() {
  member_variable_ = 1;
}

MyTest() {
  MyClass tested_class;
  tested_class.MyFunc();
  assert(tested_class.member_variable_ == 1);
}

?

Да, очень полезные тесты. Согласен. Пишешь код в классе, а потом пишешь в тесте проверку, что все операции в функции действительно выполнились.

 

Показать больше  

Судя по коду я попал в точку, ты вообще не понимаешь о чем говоришь  Флажки блять в классе. Ты ебанутый?

Узри же, МАГИЮ https://google.github.io/googletest/gmock_cook_book.html#OrderedCalls

  Grohuf написал 04.06.2024 в 13:19:

Я просто опустил шаблонную магию, чтобы было легче читать. Так-то понятно, что будет создан шаблоном код, который вызывает this->AddRef().

Извне? AddRef чья обязанность позвать? Нету ThreadSafeRef/WeakThreadSafeRef?

  Grohuf написал 04.06.2024 в 13:19:

Это писал не я, а чел из гугла. Я просто это фиксил (апстримил, офк).

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

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

  Grohuf написал 04.06.2024 в 13:19:

Ты еще не знаешь проблем шаредптра...совсем плох.

Расскажи.

  Grohuf написал 04.06.2024 в 13:19:

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

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

Еще идеи?

  GoldRobot написал 04.06.2024 в 13:34:

Судя по коду я попал в точку, ты вообще не понимаешь о чем говоришь  Флажки блять в классе. Ты ебанутый?

Узри же, МАГИЮ https://google.github.io/googletest/gmock_cook_book.html#OrderedCalls

Чел, я работаю над хромиумом, который делают в гугле. 

https://chromium.googlesource.com/chromium/src.git
Если у тебя сложности с поиском

  GoldRobot написал 04.06.2024 в 13:34:

Извне? AddRef чья обязанность позвать? Нету ThreadSafeRef/WeakThreadSafeRef?

Там все написано. Напряги извилины чуть-чуть.

  GoldRobot написал 04.06.2024 в 13:34:

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

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

Ты хоть в курсе, как написана библиотека std? Не просто так многие вещи из нее в гугле забанены.

  GoldRobot написал 04.06.2024 в 13:34:

Расскажи.

Использование std::make_shared является обязательным. Создал объект как-то не так - привет лишние тормоза. Никаких средств быть уверенным, что объект создается именно так. Если тебе неудобно - похуй, изворачивайся. Нельзя передавать сырой указатель, поэтому всегда лишние работы со счетчиком, которые в многопоточной среде должны быть атомарными.

Ебать вы тут насрали ходя вокруг да около. Сейчас вам батя все объяснит. 

Почему сложно тестировать многопоточный код:

Допустим у вас есть тред(бизнес-задача) А у которого есть состояния перед локом->лок->отдал лок и тред (бизнес-задача) Б с таким же состоянием (3 состояния)

Получается чтобы протестировать все поведение вам нужно в рамках теста сделать 3х3 (9 кейсов сочетаний состояний) и это только в статике. А есть ещё динамика, когда начинают в одном состоянии но другой прошел чуть быстрее а потом замедлился.

А когда число состояний увеличивается количество тест кейсов растет экспоненциально.

Опять же можно прибегнуть к виртуальному времени, как Vova упомянул, но это если у каждого из тредов есть возможность собственно то самое виртуальное время подсунуть. Есть точки где треды обращаются к Clock за временем.

Если же там чисто CPU не ожидающий, не блокирующийся код, то виртуальное время можно засунуть в жопу.

А когда в бизнес-логику напиханы точки входа для тестов. Типо давай сюда засунем Thread.sleep(clock.nanos(1)) и будем мокать клок в тестах))))0 то от такого кода хочется помыться 

P.S. Даже то же виртуальное время в разы лучше работает когда пишешь многопоточный код конкарент агностик вещами типо реактивщины/корутинщины

https://kotlinlang.org/api/kotlinx.coroutines/kotlinx-coroutines-test/kotlinx.coroutines.test/-delay-controller/advance-time-by.html

https://nexocode.com/blog/posts/fast-reactor-tests-with-virtual-time/

Моканье времени - вполне обычная практика. Хотя чаще надо мокать тики процессора, так как именно они в нормальном коде используются для пауз и измерения промежутков времени.

  Index написал 04.06.2024 в 13:43:

от такого кода хочется помыться 

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

Чекнул cppreference. Оказывается при использовании std::make_shared weak_ptr не дает удалиться памяти, занимаемой всем объектом. Ну да, логично, там же одна аллокация. Короче, говно-говном.

  Grohuf написал 04.06.2024 в 13:42:

Использование std::make_shared является обязательным. Создал объект как-то не так - привет лишние тормоза. Никаких средств быть уверенным, что объект создается именно так. Если тебе неудобно - похуй, изворачивайся. Нельзя передавать сырой указатель, поэтому всегда лишние работы со счетчиком, которые в многопоточной среде должны быть атомарными.

Чел.

Это плата за безопасность. Ты сам себе злой буратино, который потом ебеться с тем что выше.

Если нет контеншена, то атомик довольно быстро работает.

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

Если ты пишешь говно по которому даже не ясно за что оно ответственно, то ССЗБ.

  Grohuf написал 04.06.2024 в 13:42:

Никаких средств быть уверенным, что объект создается именно так

Не отработают методы, если не шаредптр сделан.

  Grohuf написал 04.06.2024 в 13:42:

Там все написано. Напряги извилины чуть-чуть.

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

Ясно.

Я удивлен что ты даже с gmock не знаком. Хотя казалось бы, не дуит, не дуит мы думали ты.

  Grohuf написал 04.06.2024 в 13:42:

Ты хоть в курсе, как написана библиотека std? Не просто так многие вещи из нее в гугле забанены.

Чел, ту хуйню которые ты написал и даешь нам как пример, согласно гугловским гайдлайнам нужно в печи нахуй сжечь.

  GoldRobot написал 04.06.2024 в 14:13:

Если нет контеншена, то атомик довольно быстро работает.

Не надо пиздеть. Атомарный инкремент гораздо медленее работает обычного инкремента.

  GoldRobot написал 04.06.2024 в 14:13:

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

Ясно.

То есть ты сельский дурачок, который не понял довольно простой пост. Там написано "Когда он создается, он не выставляет счетчик ссылок в единицу, потому что всегда он присваивается умному указателю, который инкрементирует этот счетчик на единицу." Чего там может быть непонятно - я не представляю. Походу ты совсем тупой.

  GoldRobot написал 04.06.2024 в 14:13:

Я удивлен что ты даже с gmock не знаком. Хотя казалось бы, не дуит, не дуит мы думали ты.

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

  GoldRobot написал 04.06.2024 в 14:13:

Чел, ту хуйню которые ты написал и даешь нам как пример, согласно гугловским гайдлайнам нужно в печи нахуй сжечь.

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

Залил очень крутую тему на гитхаб залайкате чтобы в реки кинуло
думаю 1000+ лайков должно дать если запостят в каком нибудь телеграм канале.
https://github.com/ManulMap/malstring

#ХОЧУВРЕК

#ВРЕК

  Grohuf написал 04.06.2024 в 14:20:

Не надо пиздеть. Атомарный инкремент гораздо медленее работает обычного инкремента.

Хорошо, уговорил, ведь я этого и не пиздел.

  Grohuf написал 04.06.2024 в 14:20:

То есть ты сельский дурачок, который не понял довольно простой пост. Там написано "Когда он создается, он не выставляет счетчик ссылок в единицу, потому что всегда он присваивается умному указателю, который инкрементирует этот счетчик на единицу." Чего там может быть непонятно - я не представляю. Походу ты совсем тупой.

О, я легко объясни, чего не понятно.

Если 

  Цитата

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

умный указатель инкрементирует при copy/assign/конструкторе счетчик, то он УЖЕ будет 1. На момент вызова PostTaskOnWorkerThread(this, &A::SomeMethod); его конструктор УЖЕ отработал. Ведь от этого умного указателя и отнаследовался класс. А внутри этой твоей PostTaskOnWorker создается, логично, новый умный указатель который подумает до 2.

Unless кто-то не умеет в мув семантику, не знает что такое RVO, и сделал буквально как ты написал. Что у тебя assign/copy constructor инкрементит, а просто конструктор нет, и потому можно создать объект с НУЛЕМ. Но тогда даже в синхронном однопоточном коде ты получишь абсолютно туже хуйню, что как-только умрет в PostTask последний референс, у тебя delete позовут.

Почему ты такой тупой? У тебя там какая-то лапша из дерьма написана, и я хуй просышь что за лапша. Объясни нормально.

Грохув кто-то прочитал гугловые стандарты, даже абсеил, нихуя не понял, но решил что слишком умный. std::shared_ptr специально сделали только с атомик версией. Потому что нирли нихуя не стоит, если ты не используешь многопоток, и чтобы не усложнять жизнь.

Если у тебя есть какой-то кровь из носу нужный заоптимизировать кейс, то возьми shared_ptr имплементацию, и вырежи к хуям атомики. А лучше возьми имплементацию boost::local_shared_ptr (хуй ты об этом знаешь я подозреваю).

А std::enable_shared_from_this, если ты блять не подумал, сделан именно так как сделан что бы не ебаться с кодом из твоего примера. Именно потому там внутри weak_ptr всегда создается. Именно потому из объекта, который создается вголую без shared_ptr, ты не можешь сделать shared_ptr, в отличии от твоего примера.

И даже если ты сделаешь

class A: public std::enable_shared_from_this
{}
auto aptr = new A{};
std::shared_ptr<A>(aptr)

Оно всеравно корректно отработает. Представь, блять, себе, на само деле не обязательно make_shared звать на самом деле, можно и ручками. Достаточно звать shared_from_this() когда уже будет ясно кто должен чистить объект, будет овнер, собственно появится шаред птр. А даже если не сделать этого, выкинется просто эксепшен. Умно, не правда ли?

За тебя уже подумали. За тебя уже сделали. Сделали как надо. Бери и пользуй. Либо хотя бы перенимай опыт.

Из-за таких кодеров индексы ловят инфаркт, а дуиты смеются с плюсов застряв в С98. Не делайте так.

Я конечн лайкнул, но как только лайкнул пришло письмо:

  Grohuf написал 04.06.2024 в 14:20:

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

Cмотря на то как ты пишешь тесты:

  Grohuf написал 04.06.2024 в 13:19:

Ты про свои гениальные тесты вида:

MyClass::MyFunc() {
  member_variable_ = 1;
}

MyTest() {
  MyClass tested_class;
  tested_class.MyFunc();
  assert(tested_class.member_variable_ == 1);
}

?

Да, очень полезные тесты. Согласен. Пишешь код в классе, а потом пишешь в тесте проверку, что все операции в функции действительно выполнились.

Показать больше  

Делаю логичный вывод что нет, нихуя не знаком.

  GoldRobot написал 04.06.2024 в 16:02:

умный указатель инкрементирует при copy/assign/конструкторе счетчик, то он УЖЕ будет 1. На момент вызова PostTaskOnWorkerThread(this, &A::SomeMethod); его конструктор УЖЕ отработал. Ведь от этого умного указателя и отнаследовался класс. А внутри этой твоей PostTaskOnWorker создается, логично, новый умный указатель который подумает до 2.

Класс A не является умным указателем. Ахаха.