Fork me on GitHub
#timbre
<
2023-10-18
>
Jan Tore Stolsvik07:10:12

Hi! I am trying to create a function which will log something, and I would like to test what it logs. There might be a way to test the output with redefs, would love a pointer on how that is done if anyone has suggestions. Second point, by first reaction was to just pass the log function as an argument

(keyword-tracker-log-and-reset timbre/info keyword-counts)
However this is not allowed as it is not a function, but a macro. Maybe I am missing something here, is there a way to pass these as functions? And I am also curious why these are macros in the first place, and not just functions? In my own projects I have argued for using functions over macros for several reasons, but it feels like I am missing some macro benefit :)

1
Peter Taoussanis12:10:51

Hi Jan! > Hi! I am trying to create a function which will log something, and I would like to test what it logs. To clarify: you mean that you want to write an appender function for Timbre, or just that you want to write a function for your application that happens to log using Timbre? In both cases, how to capture output will depend on what appender is actually doing the outputting. For example, if you’re using the standard console/print appender - with-out-str should do the trick since that appender just outputs to *out* . If your appender is outputting to something besides *out*, then you’ll need to rebind or redef whatever’s relevant for that appender. > Second point, by first reaction was to just pass the log function as an argument To clarify: what exactly are you trying to accomplish by passing timbre/log as a function argument? > is there a way to pass these as functions? And I am also curious why these are macros in the first place, and not just functions? There are underlying log functions, but using these directly is generally discouraged unless you’re quite sure about the tradeoffs. Timbre’s main consumer API consists of macros since these allow things like auto-gathering callsite info, supporting compile-time elision, more efficient expansions in some cases (doing some work at compile-time when possible), etc.

Jan Tore Stolsvik10:10:26

Thanks for good answers. I ment that I want to write a function for my application that happens to log using Timbre. It makes sense that I can bind something to capture the output. Its just that the logging is a side effect, and I prefer to send these in as functions or return values which inform side effects later. If I can pass inn timbre/log as a function, in my test I can pass in a spy instead where I can evaluate if it was called with correct arguments. I could also make the function return what to log and log it outside to make the function pure. I will stick to using macros for now, as I am not sure about the tradeoffs, and thanks for the pointers to what pros there are. I will read up on that 🙂

👍 1