To execute the observable you have created and begin receiving notifications, you call its subscribe() method, passing an observer.
The diagram illustrates a source Observable that emits three values and then after some time passed, completes. There are cases where the “subscribe and assert” pattern has some downsides and where it may not be the best pattern to follow. Instead of bubbles, RxJs introduced the following syntax when writing marble tests in our code. You probably remember the old days, when we wrote tests in AngularJS and stub promises like this: The code above is completely valid — unlike observables, promises are always asynchronous. And the answer is Marble testing with RxJs’s testing utilities. Here are a few more resources to learn about marble testing: Follow me on Medium or Twitter to read more about Angular, Vue and JS! So that’s no solution. I prefer to work directly with the testing tools of RxJS. You get the idea, right. Let me show you three ways to correct the above. We’ve got our appComponent who need to get some users from a Service. Nice, this is already much cleaner! How cool is that! We destructure the expectObservable method from the RunHelpers and use it to compare our pizzaIngredient$ to meet our expectedMarble with the expectedIngredients. This test defines a cold observable that waits two frames (--), emits a value (x), and completes (|).
With the use of the knowledge described in the “Testing asynchronous RxJS operators” blog post, we can create ourselves a test that not only asserts that the correct items are emitted but also asserts that they are emitted at the correct time. We need a way to “terminate” the Observable and extract the type T out of it. Isn’t it? If you came across this blog post, I assume that you already wrote some lines of reactive code with RxJS if not a thousand. Here are a few more resources to learn about marble testing: The official docs. . It’ll be loaded on the initialization of our component (ngOnInit). But hang tight, there is a way to solve those problems. We delay each emission with the specified value from the cookbook using the delayWhen operator. Marble testing, on the other side, offers a nice, clean, and declarative way to test your Observables. As explained in my other blogpost about “Marble testing with RxJS testing utils” we create ourselves a fresh instance of the TestScheduler. In these tests, I am using the npm package jasmine-marbles which is a helper library that provides a neat API for marble tests if you are using jasmine (which is used per default in Angular).