dry-rb/chat

WE MOVED TO ZULIP => https://dry-rb.zulipchat.com <=

George Millo

@georgemillo

how do people test their dry-v schemas, if at all?

I started writing some custom RSpec matchers, then I realised that my spec files were practically identical to my schemas themselves:

# schema:
required(:name).filled
optional(:age).maybe

# spec:
expect(schema).to have_required_key(:name).filled
expect(schema).to have_optional_key(:age).maybe

which is better than no tests at all, but tests take time to write, and now I'm writing 2x as much code for very little extra benefit

what are people's thoughts on writing tests for their schemas? do you find it worth the effort?

George Millo

@georgemillo

(I'm thinking that if I'm going to create custom matchers, my time is probably better spent creating them for Reform validations, which of course use dry-v anyway, but the matchers themselves will have to be different)

Christopher Dennl-Ortega Arrieta

@cdennl

@georgemillo don't test the schema but the instance which uses the schema

George Millo

@georgemillo

@cdennl I thought as much. In my case that would be Reform

Christopher Dennl-Ortega Arrieta

@cdennl

the schema alone is pretty meaningless

@georgemillo yes

or the model / op which uses the schema

George Millo

@georgemillo

there's a gaping hole in the Reform ecosystem for some smart RSpec matchers that test the validations

Fran Worley

@fran-worley

@georgemillo I've started moving away from tests like that. I test the actual result. I.e if I pass in this input, I expect to get the following errors. I think you get a more reliable result that focuses more on what matters (when my object is valid vs invalid and why) than the exact code I used to get there. Less coupling on the exact implementation therefore less brittle tests etc.

Fran Worley

@fran-worley

Plus as soon as you get advanced edge cases that depend on injected objects (say current user) you either end up testing manually or having such a complex matcher that it slightly defeats the point of having such a clean implementation library like dry-validations ! (Just my personal opinion of course 😜)

Lucas Hosseini

@beauby

^— :+1:

George Millo

@georgemillo

@fran-worley yeah, my custom matchers work like you described (passing in input, seeing if its valid), rather than testing the actual code (not even sure how you'd do that, presumably there's some way to reflect on the Schema class to figure it out)

where I realise I've gone wrong through is testing things at such a low level, i.e. at the level of the schema itself rather than the place that uses it (e.g. a reform form)

Fran Worley

@fran-worley

@georgemillo Sounds really cool, might do a minitest equivalent and actually use it in Reform :)

George Millo

@georgemillo

I opened at issue over at Reform if anyone wants to weigh in on this further: trailblazer/reform#414

Hannes Nevalainen

@kwando

hmm, is there a way to check that error messages have been defined for all predicates? would be nice to just tell "something" to check if I have provided error messages for all custom predicates (don't like to blow up on Dry::Validation::MissingMessageError)

George Millo

@georgemillo

https://github.com/icelab/dry-web-skeleton/blob/master/docs/structure.md

This doc has a link to a gem called dry-component but the link is dead

has this gem been renamed?

oh wait, Google suggests that this is the old name for dry-system

amirite?

Nikita Shilnikov

@flash-gordon

yep

Andrew Thauer

@andrewthauer

Question - I’m looking at using dry-rb to build a re-usable gem that allows the consuming application to define & configure the persistenance layer, and other infrastructure related dependencies. I’ve got this more or less working when I explictly ask the container to resolve the dependency just before I need the service.

class SaveMyEntity
  def call(entity)
    my_repo = MyContainer[‘persistence.my_repo’]
    my_repo.save(entity)
  end
end

I’m wondering if I can also use either dry-auto_inject and/or dry-system to also do this? However, from what I can see, using the auto loading and the auto injector work differently.

Import = Dry::AutoInject(MyContainer)
class SaveMyEntity
  include Import[‘persistence.my_repo’] # throws Dry::System::ComponentLoadError: could not load component
end

Tim Riley

@timriley

@andrewthauer That should work. How are you setting up that “my_repo” registration?

Andrew Thauer

@andrewthauer

Sorry, I realized that using Application.inject vs Dry::AutoInject seem to behave differently. My mistake, the above example does work, but the Application.injector (suggested by the dry-system example), throws the above exception.

Does one lazy load dependencies and the other does not?

Tim Riley

@timriley

Dry::System.injector will give you an injector that lazy loads for containers that aren’t finalized, yes

But it’ll only lazy load according to certain strategies (though we’re actively improving that), so if your “persistence.my_repo” registration falls outside of that, it’ll not work

Andrew Thauer

@andrewthauer

Import = Dry::AutoInject(Container) # works
Import = Container.injector #  throws Dry::System::ComponentLoadError: could not load component

I’m currently calling one of those 2 lines inside a module pretty much when the gem is initially loaded. The first line seems to work, but the 2nd throws the error when I use the Import in a subsequent ruby file. Should I be deferrring these until after the consuming application has a chance to register it’s own dependencies?

Basically, just trying to figure out the correct pattern to use moving forward. I’m not sure, if I should be bothering with dry-system in my case or just leverage dry-container and possibly dry-auto_inject.

Tim Riley

@timriley

You’re probably seeing an error with dry-system’s injector because it’s trying to do the lazy load as soon as it is included into a class

whereas plain auto-inject doesn’t do any lazy loading at all

which is why it doesn’t bother to resolve the deps until you actually initialize that class

in dry-system master branch we’ve actually changed lazy loading so it does it upon class initialization too, not at include-time anymore

so that might be worth trying

but yeah, in general with dry-system for a non-finalized container, if the lazy loading fails, you’ll get an error

for a finalized container, your deps should all be registered anyway, since the container is frozen at that point

Andrew Thauer

@andrewthauer

I don’t recall actually using the finalize! method (although I did see it). Is this required or not? I don’t have any issues having the consumer of the gem have to explicitly call something to finalize and freeze the dependencies. Just need to make sure things get loaded correctly without a wierd order of operation issues. Is there particular pattern you would suggest to allow for a consumer to configure dependencies?

Tim Riley

@timriley

So you’re expecting the consumer to supply their own container?

Andrew Thauer

@andrewthauer

Or configure pieces of the main gem’s application container. It’s kindof two old. The initial usage of this new domain model will be integrated into 1 system which I’d like to leverage the existing persistence there. However, in the future the same domain logic could be useful in other applications. Further thinking down the road, it might make senes to extract out persistence to a shared application in an SOA environment. I figure putting the architectural boundaries now should afford making this refactoring much easier down the road (i.e. swapping out a repository from a database call to a web service call).

Tim Riley

@timriley

right, OK. So if you’re providing a container and it’s a Dry::System::Container, then I’d expect a boot sequence for the container to be something like this when running in a production-like environment:

# Require the container
require_relative "main/container"

# Load files with manually registered dependencies
Main::Container.require "component/container/persistence"

# Finalize the container, which does auto-registration if you've configured it
Main::Container.finalize!

That way your container reaches a reliable state right up front and is frozen from there

the lazy loading feature of non-finalized dry-system containers is really meant for isolated unit testing, where you want it to be fast, so you load up an empty container (don’t finalize) and then rely on the lazy loading to get just the right combination of components you need for your unit test to run

Tim Riley

@timriley

If you don’t want to require your consumers to undergo a “boot” process like this, then maybe dry-system is not what you want. (But then you’d do without features like auto-registration etc., but I’m not sure how important they are for you in this thing you’re building)

Andrew Thauer

@andrewthauer

I think, I’d be fine having the consumer go through a boot process. The initial consumer will be a rails application. So my initial thought is to have config/initializer that does the boot process your suggesting (where the middle line loading the rails defined repositories, etc.). I’ll have to try out a couple things to see what works. Thanks for you help!

George Millo

@georgemillo

is there any documentation for dry-view?

Valentin Trinqué

@ValentinTrinque

Hi guys, I have some trouble using dry-validation. I am trying to ensure that some ids I receive from my API are actually valid records in my database. In my form I have this :

property sender_ids
required(:sender_ids) do
  filled? & array?
end
rule(valid_senders: [:sender_ids]) do |sender_ids|
   Contact.exists?(id: value(:sender_ids))
end

But it raises the following error :

POST /letters with valid data returns the new letter
Failure/Error:
  rule(valid_senders: [:sender_ids]) do |sender_ids|
    Contact.exists?(id: value(:sender_ids))
  end

NoMethodError: undefined method `with' for false:FalseClass
# ./.gems/gems/dry-validation-0.10.4/lib/dry/validation/schema/value.rb:96:in `rule'
# ./app/forms/letter/create_form.rb:31:in `block in <class:CreateForm>’

Do you have any idea ?

Where communities thrive

People

Repo info

Activity