These are chat archives for dry-rb/chat

Aug 2017
Gustavo Caso
Aug 16 2017 05:11
There is not a manual or section in the dry-rb org website
It would be interesting to have one by the way :)
Here are some examples
module Types
  include Dry::Types.module
  Statuses = Types::Strict::String
    .enum('draft', 'published', 'archived')
module Types
  include Dry::Types.module
  StringList = Types::Strict::Array
    .constrained(min_size: 2)
@ffloyd hope this examples helps
Justin Grimes
Aug 16 2017 16:29

Hi all, I'm in the middle of introducing cleaner approaches to a team on an existing rails project. The transaction lib is nice but I'm having an internal debate with myself on unit testing approaches. It's straight forward to test operations in isolation, however when wiring operations together into a transaction, most examples I have seen tend to lean towards writing an integration test that ends up doing any number of things that the operations being wired together may do, I'm not a big fan of that approach since an operation may eventually do some dirty IO(like a DB call) operation that isn't relevant to the transaction orchestrating the operations correctly.

I've considered mocking the layer below the transaction which would be the operations and passing data between them but that leaves the potential for the output of one changing later on and the test wouldn't necessarily fail and mocking operation is a little more difficult it seems with rspec which was complaining about using expect_any_instance_of which I know is a code smell and wasn't a preferred approach either.

If I have to go down the route of creating test doubles for all my IO related things that get injected in at testing time, I'd prefer not to do that, the amount of work across the application to do that piece is significant and there are some domain related concepts that I'd have to spend more time rectifying that I'd rather put off to a later time.

Any successes, failures or advice anyone can give?

Nikita Shilnikov
Aug 16 2017 20:20
@grimesjm I don't bother with that kind of isolation in tests. I run every spec in a DB transaction and roll back changes afterwards. Instead of mocking DB calls, I use ROM and make clean interfaces using repositories, this way I know where all the queries are executed (I'm not a big fan of lazy loading) and can mock a repo in specs easily. However, I also keep all exeternal dependencies wrapped in some kind of gateways, including sidekiq workers and alike and mock them in specs