These are chat archives for dry-rb/chat

1st
Feb 2018
Spencer Goh
@dymaxionuk
Feb 01 2018 09:52
Hi a question about testing strategy...
looking at berg-master, it seems that you guys have opted to mostly approach using end to end feature tests
operations don't seem to be tested in isolation at all. What's the motivations around this? Is not part of the benefit of functional style operations is that they can be tested outside of the system?
Tim Riley
@timriley
Feb 01 2018 09:56
@dymaxionuk absolutely. That codebase is not a good example of this, unfortunately.
You can see the beginnings of some better tests in the dry-rb/dry-web-blog project
Spencer Goh
@dymaxionuk
Feb 01 2018 10:01
so it looks like the way it steers you, is that the booting & registration of objects into a container, should be essentially some pre-configuration of those objects... but the object itself is unit tested already outside of this...
eg. you have an adapter for system_x, that you unit test, and perhaps integration test also... then your app sets up that adapter inside of container.boot {} and registers thatadapter for use elsewhere in your app
the only time that wiring up code is tested is in your end to end tests
or by firing up the app locally and playing around with it... so you have to in some sense.. write all that hook code blind...
Tim Riley
@timriley
Feb 01 2018 10:03
In a sense, yes. Though auto-injected dependencies from the container are also tested when you do MyOperation.new in a unit test
You should absolutely still write higher level integration tests though
Spencer Goh
@dymaxionuk
Feb 01 2018 10:04
so if I wanted to do a MyOperation.new in unit test, what's the bare minimum I would need to require for a dry-web-road app... to test that opreation...
i need all the IOC container warm up code
so loosk like (depending how much you deide to stub out) i still need a lot of my app code
which does the wiring up
so I have MyOp that requires the db_adapter, and some other stuff which is injected in... I stub out my db adapter.. fine... but in order to get the other stuff injected.. i still need the IOC container setup during my test.
so is spec_helper then just going to fire up the entire app?
seems like i have to pull quite a large surface area, just to test an operation... or perhaps I'm misunderstanding something.
woudl be good to find a "model" example of testing an operation... which has dependencies injected, but those deps come from dry-web-roda app booted containers.
Tim Riley
@timriley
Feb 01 2018 10:14
@dymaxionuk we don’t dry-system containers in tests, which means none of the app boots. Then when you require a single file for your operation and .new it (and if you choose not to provide that operation’s dependencies as test doubles), then dry-system will resolve only those injected operations and make them available for the test
It’s really to the contrary of your conjecture above, having dry-system in place actually allows for single unit tests to be incredibly efficient but still easy to write
Spencer Goh
@dymaxionuk
Feb 01 2018 10:19
"we don’t dry-system containers in tests" I can't quite read this...? ;-)
Tim Riley
@timriley
Feb 01 2018 10:19
Sorry, we don’t finalize them
Spencer Goh
@dymaxionuk
Feb 01 2018 10:21
so you basically spec_helper requires the container... but never finalizes, so all that's done is the init code... so you test 1 operation... although you include the main app container... it's relatively fast, because all it's doing is doing the lightweight inits... the only instantiations are done for the required IOC dependencies..
Tim Riley
@timriley
Feb 01 2018 10:22
@dymaxionuk you’ve got it
Spencer Goh
@dymaxionuk
Feb 01 2018 10:22
so the unit test would still fire up container.. and require all system/boot/** etc. but that's simply registering the procs
Tim Riley
@timriley
Feb 01 2018 10:22
nope
Spencer Goh
@dymaxionuk
Feb 01 2018 10:22
so it's pretty lightweight...
Tim Riley
@timriley
Feb 01 2018 10:22
it doesn’t even do that
you literally require “my_app/container” and do nothing else
and then the auto-injection mixin will have the container only resolve what it needs
and if some of those deps require a bootable component, then the container will only boot that component as required
Spencer Goh
@dymaxionuk
Feb 01 2018 10:23
ah nice..
Tim Riley
@timriley
Feb 01 2018 10:23
it’s all done lazily
Spencer Goh
@dymaxionuk
Feb 01 2018 10:23
so the missing bit in my understanding.. is that the auto-inection mixin will walk through the load path to decide what file to load and boot into container
Spencer Goh
@dymaxionuk
Feb 01 2018 10:34
ok so the stuff in <root_app>/system/boot/*.rb how does dry-auto-inject find these items to boot up , in a subapp/operation unit test scenario - where a root_app component is injected into subapp. I didn't spot where it does this actual resolution...
Also btw, I noticed your dry-web-roda CLI code gen doesn't generate the spec_helper.rb one might expect....
namely it doesn't require the sub-app containers This might leave some ppl a bit flummoxed if they didn't spot it :smile: (?)
Tim Riley
@timriley
Feb 01 2018 10:50
@dymaxionuk dry-system will see if there’s a matching file in boot/ based on the registered name of the dependency
Tim Riley
@timriley
Feb 01 2018 11:14
@dymaxionuk would you mind filing an issue about the generated spec_helper? I agree it should be there!
Spencer Goh
@dymaxionuk
Feb 01 2018 11:30
@timriley done! thanks. dry-rb/dry-web-blog#10
@timriley I also raised this - https://discourse.dry-rb.org/t/dry-web-roda-roda-flow-plugin-causing-routing-wildcard/461
if not intended, I can raise an issue for this also... do let me know. cheers
not sure if @AMHOL is around... guess roda-flow is his baby. thanks.
@dymaxionuk using roda-flow from Github master branch should work now
Spencer Goh
@dymaxionuk
Feb 01 2018 15:40
@AMHOL thanks!
Andy Holland
@AMHOL
Feb 01 2018 15:52
NP :)
Chris Richards
@cmrichards
Feb 01 2018 19:21
i'd love to see more complicated examples of rom. All I've seen is demonstrations of basic functionality, such as basic associations.