Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Andy Holland
@AMHOL
Could add a test mode
Piotr Solnica
@solnic
how would that work?
Andy Holland
@AMHOL
Was thinking rather than https://github.com/dryrb/dry-container/blob/master/lib/dry/container/registry.rb it would not raise on registration of a duplicate key
Piotr Solnica
@solnic
a simple way would be sth like container.stub(‘persistence.foo’ => double())
Andy Holland
@AMHOL
But that would overwrite the existing value
Piotr Solnica
@solnic
of course only in test mode
Andy Holland
@AMHOL
Yeah, but it could be done via configuration
Piotr Solnica
@solnic
it would have to remember original value and restore it on teardown
this would be super useful
Andy Holland
@AMHOL
Yeah, still not sure of the best way to go about it
Piotr Solnica
@solnic
we won’t know until we try
I can tell you I have use cases for local-per-test stubs and global
global in the sense that I have a dep that I want to stub completely for all tests
it’s my thing, there are separate tests for it so I’m safe, but for all the tests that use objects which rely on it, I want to use a stubbed version
Andy Holland
@AMHOL
Create something like dry-container-rspec or something?
Piotr Solnica
@solnic
no, this doesn’t feel needed
it could be an internal thing, non-test-framework-specific
Andy Holland
@AMHOL
Feels weird to update the actual library just for testing though
Piotr Solnica
@solnic
I dunno
no super strong opinions
otoh it feels essential to have this kind of an interface for tests
Andy Holland
@AMHOL

You happy with

Dry::Container.configure do |config|
  config.registry = Dry::Container::Test::Registry.new
end

For the things you want to stub for all tests?

Piotr Solnica
@solnic
if we could collapse that into Dry::Container.test_mode! then yes, I guess, need to think about this :)
Andy Holland
@AMHOL
Yeah
Benjamin Klotz
@tak1n
at our company I'm trying to introduce dry-constructor as injector lib for our service objects
we use initializers and specify default collaborators, but for specs u can inject mocks and unit test the service object itself
is there a way to specify default values for dependencies injected by dry-constructor?
eg :
class DoThings
  def initializer(collab = Collaborator.new)
    @collab = collab
  end
end
and in specs u can do DoThings.new(double).call
in controller or anywhere else u do DoThings.new.call
Andy Holland
@AMHOL
@tak1n, dry-constructor is just for defining the constructor with the args to inject and assigning them to ivars, might be worth looking at Dry::AutoInject
@tak1n if you're using Rails, worth talking to @solnic as he recently implemented IoC in Rails and said it worked really well
Benjamin Klotz
@tak1n
@AMHOL okay thx :)
Andy Holland
@AMHOL
NP :)
Hannes Nevalainen
@kwando
This message was deleted
nvm, it won't work for more complex cases anyway
Piotr Solnica
@solnic
@kwando hmm?
Hannes Nevalainen
@kwando
let(:container){ Hash.new{ |_,k| MyAppContainer.resolve(k) }
This message was deleted
then override as needed in tests
Piotr Solnica
@solnic
@AMHOL can we push new dry-container release? I’d like to get off of master in rodakase
Andy Holland
@AMHOL
@solnic yeah, do you have permissions on rubygems?
Piotr Solnica
@solnic
@AMHOL I don’t think so
Piotr Solnica
@solnic
@AMHOL can dry-configurable be used on an object instance level?
Andy Holland
@AMHOL
No, there was a reason why I made it like that but that was a while ago now
Piotr Solnica
@solnic
it’s ok, just curious
Andy Holland
@AMHOL
Think I just thought configuring instances was a bad idea, should just use DI
To compose behaviour
Piotr Solnica
@solnic
@AMHOL could you add me to dry-container on rubygems and/or release a new version?
Andy Holland
@AMHOL
@solnic rubygems says you've got access?