-
Notifications
You must be signed in to change notification settings - Fork 120
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Development/Test Mode #42
Comments
Yeah, that makes some sense. I definitely want to have more logging in the library everywhere which can be enabled, so big +1 on logging requests there, though I'm not sure if I'm sold on the DI route yet. FWIW: what we do currently is set up a "development" project and then use a separate key for prod vs dev setups. We then look at requests going into the segment.io debugger when figuring out what is being sent. |
ok you'll be able to stub requests when that's pushed, i'm not sold on di in ruby either. http://david.heinemeierhansson.com/2012/dependency-injection-is-not-a-virtue.html |
Thanks! I'm not going to argue about DI or not even though it would add more extensibility. |
@travisjeffery I'm assuming you can enable request stubbing by passing: Analytics.init({ stub: true, ... }) Correct? Any chance you could add a bit of documentation on Analytics#initialize? It's a little odd that the setup process isn't documented in the README. I can submit a PR if you folks need some help getting that into shape. |
@olivierlacan stub's available in v2, which is namespaced and not a singleton. so you would do:
|
Would be awesome to have a 'dev mode' when instead of actually sending requests it would do some action (log for example).
This could be implemented as simple dependency injection on Client and Consumer.
Consumer would instead of doing
Request.new
do@requester.new
Like:
The text was updated successfully, but these errors were encountered: