You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+29Lines changed: 29 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -93,6 +93,35 @@ During the `perform` method, you should have stored the results as instance vari
93
93
94
94
The caller can check the success or failure of the use case by calling the `success?` and `failure?` helper methods. If the use case has had a failure, the errors will be available on the standard `errors` collection.
95
95
96
+
## Testing
97
+
When a use case is used in another class to perform an action or query, it can be handy to use a mock instead.
98
+
To do so, `require 'use_case_mock'` in your specs and use the UseCaseMock class to create the state of the use case after the perform action. This is particularly handy when you want to add errors and keep a stable use case behaviour.
99
+
Adding errors to the mock will make the use case failed? but not invalid? if `perform!` is called.
100
+
101
+
```ruby
102
+
require'spec_helper'
103
+
require'use_case_mock'
104
+
105
+
RSpec.describe MyParentClassdo
106
+
107
+
before do
108
+
use_case =UseCaseMock.new(results: [])
109
+
use_case.errors.add(:base, 'Could not fetch results from 3rd party API')
After checking out the repo, run `bin/setup` to install dependencies. Then, run `rake spec` to run the tests. You can also run `bin/console` for an interactive prompt that will allow you to experiment.
0 commit comments