These are chat archives for dry-rb/chat
Next-gen ruby libs! » github.com/dry-rb » website: https://dry-rb.org » forum: https://discourse.dry-rb.org
module Types include Dry::Types.module Statuses = Types::Strict::String .enum('draft', 'published', 'archived') .default('draft') end
module Types include Dry::Types.module StringList = Types::Strict::Array .member(Strict::String) .constrained(min_size: 2) end
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?