Testing NgRx Effects: Isolate and Verify Side Effects
Test NgRx Effects by treating them as pipelines that transform action streams. Provide a source action and mock dependencies to verify the effect dispatches the correct success or failure action.
Why it exists
Effects manage side effects like API calls, which are inherently asynchronous and can fail. We need a reliable way to test that our app handles both success and failure scenarios correctly without actually making network requests or hitting a database.
The mental model
Think of an Effect as a pipeline. An observable stream of actions goes in one end, and another observable stream of actions comes out the other. Your test provides a controlled input stream (e.g., a loadItems action) and checks if the output stream emits the expected action (e.g., loadItemsSuccess or loadItemsFailure).
How it works
You test an Effect class directly, not through the entire NgRx store setup. You instantiate the Effects class, providing mock implementations for any services it depends on, like an API client. You also provide an Actions observable. A common pattern uses Angular's TestBed to provide mocks and a library like jasmine-marbles or rxjs/testing to create cold or hot observables that simulate the action stream and assert the output.
When to use it
Always test your Effects, as they contain critical application logic. Focus on testing the mapping from an input action to one or more output actions. For example, test that a login action, given a successful API response from a mocked service, results in a loginSuccess action. Also, test the failure path: if the mocked service throws an error, does the effect correctly catchError and dispatch a loginFailure action?
When not to use it
Don't use Effect testing to verify the logic inside your services; that's what service unit tests are for. The Effect test's scope is purely to confirm that the Effect correctly orchestrates the call to the service and dispatches the right follow-up action based on the service's response. Don't test reducer logic here either; that's a separate unit test.
One canonical example
To test an effect that fetches user data, you first set up your test environment using TestBed, providing a mock UsersService and the Actions stream. Then, create a cold observable for the input actions$ that emits a loadUsers action. Configure your mock UsersService to return a successful response. Finally, define an expected cold observable that emits a loadUsersSuccess action with the user data as its payload. You then run the effect and assert that its output matches your expected observable.
Interview question
When unit testing an NgRx Effect, what is the primary goal?
- a.To validate the complete data flow from action dispatch to state change in the store.
- b.To confirm the reducer properly updates the state after the effect's actions.
- c.To ensure the dependent service's business logic performs its intended operation.
- d.To verify the effect dispatches the correct subsequent action based on a mocked service's outcome.Correct
Why? this is the answer
The primary goal of testing an NgRx Effect is to verify its orchestration logic: that it correctly calls a service and dispatches the appropriate success or failure action based on the mocked service's response. Testing the internal logic of the dependent service is the responsibility of the service's own unit tests, not the effect's.
Just read this? Test yourself on what you have been reading.
Read the original → ngrx.io
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles