Testing the SignalStore

[00:00:00]
>> Alex Okrushko: So let's just create some quick specs. And I'm going to do it very briefly as well, so in the app in the core. Ah, we have the cart store. Uh, this is our store that we just created, uh, let's just quickly create the cart, uh, store, spec or test doesn't matter, we'll just do the spec in this case. Right, let me just copy this and I'm going to go over what exactly some key points here in our test.

[00:00:38]
And right now again I'm using jsdom environment so. Some component testing I'll probably do differently. But this one is pure service or injectable, right, so it doesn't really matter. The way I'll do is I'll describe the test and I'll. Um, in my career, I learned to write the test without before eaches. Instead, I have the setup file. Set of function.

[00:01:09]
And within that function, I'll create my test environment. Uh, I can sometimes even pass arguments to the setup function to, uh, pre-set up certain things, provide some certain mock values already, and then that setup function, what it returns, it returns something that could be using in the test like my mock, uh, and things that's under test as well.

[00:01:35]
This is no different, and this is the approach if you Google for this. As the approach is called ciphers, ciphers, and it stands for a simple injectable functions, explicitly returning state. Um There's a number of talks on this as well, uh, yes, so highly recommend this approach. Anyhow, we now have a setup function, in the setup function, I configure my testing module, I'll provide my API URL right, because the cart store will.

[00:02:11]
It uses the ticket one, which uses the API URL, and there's also a helpful, um, a provider coming directly from Angular HTTP testing. It's called provide HTTP client testing. So it allows us to kind of capture it almost in turn. All right, and then out of this uh setup function, I'll return my store, which I inject my cart store, right? And my HTTP mock as well.

[00:02:45]
Right, so I don't have before each because in before each, you also have some global um properties let something and then before each will override that property and then you use that property within the test, it becomes a little bit. Confusing where it's come, where things are coming from, this one's very explicit, right? We call a setup function, we get our store and HTTP mock, they're not in the global scope.

[00:03:12]
And for each test, they'll be created, so in this case, in my store, uh, let me just get it here. Initially, immediately when I set up, remember, we'll load uh tickets on init, on the initialization in a hook. Right away I can say that, hey. This request I expected to get. And I expect still initially my tickets. I'll take its length to be 0 or I can do the count to be 0.

[00:03:55]
Both work, count my count to be 0, right? Uh and then. Then I'll, uh, flush the mock data for my request, so I intercepted this and I was like, here's your response. And I'll say, hey, you have one event ID and just whatever random ID it doesn't really matter. But now, once we flush this, we can read the stored data and it should be at one. And HTTP verify again, just making sure that that's uh the thing that happened.

[00:04:32]
Right, that's using the standard HTTP client testing module. Ah, we can say optimistically adds tickets and reverts an error, right, so again, this is another example where we try to add. Ah, but we would flush with the server error. All right, so we're getting the error back and it should be rolled back to one. And you see we're checking the pending status as well, and now we have the error.

[00:05:12]
So those are some of those things we can do, and the way we can test this is and indeed test. Passing. Yes. Always nice when things are passing. So this is how we would test the services, injectables, I'm using the signal store. Um, that's one. Second, again, we can do like a component test.