You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I want to provide convenient RSpec matchers for this gem (similar to your minitest assertions) and was wondering why the CaptureBackend is not used by default in test environments (but the NullBackend instead).
In my opinion this would simplify the implementation a lot, instead of mocking & replacing the NullBackend with a CaptureBackend in a block (as done currently), you'd just need to configure the Backend once (either in a spec_helper explicitly or via ENVs implicitly).
What do you think?
The text was updated successfully, but these errors were encountered:
nTraum
changed the title
Use CaptureBackend in Test
Use CaptureBackend in Test environment
Mar 17, 2015
First of all, we want to make sure the StatsD packet is actually generated inside the code block of the assert call, not before or after. So we should only capture inside the block.
Second: our test suite is big, and we generate lots of StatsD calls. This would require a lot of memory during the test run as we accumulate thousands of metrics.
In RSpec, I'd expect something like expect { ... }.to generate_statsd_call(...). You can easily do the same trick with the block here.
Hi statsd-instrument team,
I want to provide convenient
RSpec
matchers for this gem (similar to yourminitest
assertions) and was wondering why theCaptureBackend
is not used by default in test environments (but theNullBackend
instead).In my opinion this would simplify the implementation a lot, instead of mocking & replacing the
NullBackend
with aCaptureBackend
in a block (as done currently), you'd just need to configure the Backend once (either in aspec_helper
explicitly or via ENVs implicitly).What do you think?
The text was updated successfully, but these errors were encountered: