ИИ
не нужно мокать =)
ну это не замена, а дополнение. нормальная тема
Size: a a a
2020 June 22
ИИ
можно с таким-же примерно успехом еще логи грепать. на интеграционных тестах такое делаем
SP
sergey.prokhorov 11 days ago
I think at least in <team name> when we want to trace some function calls in a test we just mock this function with passthrough option and then check meck:history. What kinds of advantages would we get by using snabbkafe instead?
dmitry.fedoseev 11 days ago
it evolved from the approach that you mentioned. except you don't need to reinvent history analysis primitives over and over again, and, by and large, you don't need meck.
dmitry.fedoseev 11 days ago
in order to troubleshoot your code, you look at the logs. the core idea is that the testcases can do it for you.
dmitry.fedoseev 11 days ago
...I deliberately chose not to use meck or any kind of code introspection and rely entirely on the structured log messages instead. this makes trace specifications independent of the internal implementation and less fragile
I think at least in <team name> when we want to trace some function calls in a test we just mock this function with passthrough option and then check meck:history. What kinds of advantages would we get by using snabbkafe instead?
dmitry.fedoseev 11 days ago
it evolved from the approach that you mentioned. except you don't need to reinvent history analysis primitives over and over again, and, by and large, you don't need meck.
dmitry.fedoseev 11 days ago
in order to troubleshoot your code, you look at the logs. the core idea is that the testcases can do it for you.
dmitry.fedoseev 11 days ago
...I deliberately chose not to use meck or any kind of code introspection and rely entirely on the structured log messages instead. this makes trace specifications independent of the internal implementation and less fragile
ИИ
sergey.prokhorov 11 days ago
I think at least in <team name> when we want to trace some function calls in a test we just mock this function with passthrough option and then check meck:history. What kinds of advantages would we get by using snabbkafe instead?
dmitry.fedoseev 11 days ago
it evolved from the approach that you mentioned. except you don't need to reinvent history analysis primitives over and over again, and, by and large, you don't need meck.
dmitry.fedoseev 11 days ago
in order to troubleshoot your code, you look at the logs. the core idea is that the testcases can do it for you.
dmitry.fedoseev 11 days ago
...I deliberately chose not to use meck or any kind of code introspection and rely entirely on the structured log messages instead. this makes trace specifications independent of the internal implementation and less fragile
I think at least in <team name> when we want to trace some function calls in a test we just mock this function with passthrough option and then check meck:history. What kinds of advantages would we get by using snabbkafe instead?
dmitry.fedoseev 11 days ago
it evolved from the approach that you mentioned. except you don't need to reinvent history analysis primitives over and over again, and, by and large, you don't need meck.
dmitry.fedoseev 11 days ago
in order to troubleshoot your code, you look at the logs. the core idea is that the testcases can do it for you.
dmitry.fedoseev 11 days ago
...I deliberately chose not to use meck or any kind of code introspection and rely entirely on the structured log messages instead. this makes trace specifications independent of the internal implementation and less fragile
но он же инвазивный этот метод.
Programmer manually instruments the code with trace points - может правильнее было привязаться к шатным средствам трассировки?ИИ
sergey.prokhorov 11 days ago
I think at least in <team name> when we want to trace some function calls in a test we just mock this function with passthrough option and then check meck:history. What kinds of advantages would we get by using snabbkafe instead?
dmitry.fedoseev 11 days ago
it evolved from the approach that you mentioned. except you don't need to reinvent history analysis primitives over and over again, and, by and large, you don't need meck.
dmitry.fedoseev 11 days ago
in order to troubleshoot your code, you look at the logs. the core idea is that the testcases can do it for you.
dmitry.fedoseev 11 days ago
...I deliberately chose not to use meck or any kind of code introspection and rely entirely on the structured log messages instead. this makes trace specifications independent of the internal implementation and less fragile
I think at least in <team name> when we want to trace some function calls in a test we just mock this function with passthrough option and then check meck:history. What kinds of advantages would we get by using snabbkafe instead?
dmitry.fedoseev 11 days ago
it evolved from the approach that you mentioned. except you don't need to reinvent history analysis primitives over and over again, and, by and large, you don't need meck.
dmitry.fedoseev 11 days ago
in order to troubleshoot your code, you look at the logs. the core idea is that the testcases can do it for you.
dmitry.fedoseev 11 days ago
...I deliberately chose not to use meck or any kind of code introspection and rely entirely on the structured log messages instead. this makes trace specifications independent of the internal implementation and less fragile
(жалуются что у них нет денег на развитие beam а сами вот чо делают. всякие тулзы пишут)
V
эмм.. причем тут Кларна и Erlang/Otp команда?
ИИ
эмм.. причем тут Кларна и Erlang/Otp команда?
а это не одно и тоже? тогда сорян
SP
Нет =)
SB
-ifdef(namespaced_types).
-record(buf, {type = undefined :: undefined | stack | queue | keep_old | {mod, module()},
max = undefined :: undefined | max(),
size = 0 :: non_neg_integer(),
drop = 0 :: drop(),
data = undefined :: undefined | queue:queue() | list()}).
-else.
-record(buf, {type = undefined :: undefined | stack | queue | keep_old | {mod, module()},
max = undefined :: undefined | max(),
size = 0 :: non_neg_integer(),
drop = 0 :: drop(),
data = undefined :: undefined | queue() | list()}).
-endif.
V
похоже для того, чтобы можно было предоставить свою альтернативую имплементацию типа.
V
т.е. переопределить queue() например
ИИ
смотрю опенсоурсные проекты на Эрланге, чтоб понять как примерно выглядит трушный проект. можете объяснить для чего вот это используют:
а это трушный проект?
SB
а это трушный проект?
это то, на что щедро рассыпаны ссылки в разных ламповых блогах людей, которые контрибьютили в ребар3 и такого рода проекты, а также работали в Хероку. как по мне, звучит достаточно неплохо, чтобы по крайней мере познакомиться с их работами.
SB
т.е. переопределить queue() например
я не понимаю как это выглядело бы. как это называется, что в документации на Эрланг смотреть?
ММ
а это трушный проект?
это как бы реп хеберта. если не он, то кто?
V
я не понимаю как это выглядело бы. как это называется, что в документации на Эрланг смотреть?
судя по rebar_config это для старых версий эрланга
V
т.е. в разных версиях эрла, были по-разному немного определены типы. Если бы это было в hrl файле, я бы предположил что подобные трюки идут для различных видов сборки