Wrapping Up

[00:00:00]
>> I also wanted to mention that if you want just a collection of state machines that you just want to look at for inspiration or see how other people are modeling their application logic. There is a registry at stately.ai/registry with a ton of different machines, for example, here's an offline queue.

[00:00:23]
And so this is going to open in the visualizer and just show the machine over here. So that you could look at it and just really understand what's going on especially by playing around with the machine, sending events and seeing what happens. So I recommend you take a look at the registry, there's also xstate-catalogue, the British spelling.com.

[00:00:46]
And so in this catalog there are a bunch of, I guess, handpicked state machines where they're actually described for you. So anything that you might want to do, such as creating a multi-step form, is in the catalog. And so it talks about just the different states that it could be and the different events that can happen.

[00:01:10]
And basically, it gives you an overview of how you would model a state machine in order to accomplish whatever tasks you might want to do in an application. So I definitely recommend you check out the xstate catalogue and the xstate registry. Also, you can go to stately.ai/biz at any time for just playing around with state machines and you can save them as well.

[00:01:37]
You just log in via GitHub, and then your machines are accessible when you log in. So yeah, we're gonna be coming out with a lot more tools in the future too. The one that I'm most excited about is a visual state machine and state chart editor. Where just like I've been doing in ExcaliDraw for this whole workshop instead I could do in a state machine editor that makes it easier to create these state machines and export them directly to code.

[00:02:07]
And also integrate them with your existing state machine code in your applications.
>> We've talked from the beginning about given when then syntax, and then you just showed model based I think it's really cool that you can iterate through all those paths. Would there be a pro and con of that versus vanilla Cucumber?

[00:02:23]
If you wanted to write that and then have some other mechanism writing in plain English with the given when then like you started out and having it maybe use Puppeteer or Cypress to interact with machines for integrated testing?
>> So the question was about using these given when statements instead of just a model based testing approach where you find it all in one.

[00:02:45]
And honestly both of them are pretty much one in the same, you can do it either way. You could have separate given when then tests or you could represent it all as a test model. So the test model in model based testing is basically all of those given when then specifications combined into one machine.

[00:03:04]
So instead of saying on a, if b then c and on a if c then d and on b if e then g, it's just represented as one model where you could derive all of the given when then statements from that state machine. So they're really one and the same.

[00:03:27]
And especially if you don't want to code that state machine up front, then you can just continue to use Cucumber given when then and create all of those test statements. And then later, take a look at each of those specifications and put them into a state machine so that you can merge all of them together.

[00:03:47]
And I think that that's actually a really good technique and a good way of organically discovering how you can model your application with these specifications. In fact, I think Bob Martin talked about how these specifications are essentially a state machine anyway. So it's just different ways of writing the same state machine.

[00:04:13]
What are your recommendations for model based testing with state machines that use actors? So one way you could do this is you can mock the actors. But what I also recommend is if you go to the Xstate repo, which is @statelyai/xstate, if you look at the test files, and we look@actor.test.ts.

[00:04:39]
You're going to see an example of just the different ways that you can test these actors. So something I'd like to do is when testing the actors I just make sure that when we test them that the actors either respond immediately or respond with something that doesn't require any outside interaction with the actor.

[00:05:04]
And basically, I'm testing in my parent state machine that it eventually reaches a final state or that it reaches some specific state. And what's great about this is that I can call onDone in interpret, and so this is a callback that's called when this machine reaches its top level final state.

[00:05:26]
And so, I know if I reach that top level final state, then the interaction between the state machine and the actor was successful. So yeah, it's just a really easy way of testing that. But in general, you can mock actors, and that's something that I'd recommend unless you're doing integration testing, then yeah.

[00:05:48]
Again, if you have a direct reference to that actor, which you do in state.children, or if you're spawning in state.context directly. Then you can send events to that actor to sort of coerce it to behave in a certain way and send events back to the parents potentially. All right, there was a good question in the chat, can context be serializable or can you store anything in context?

[00:06:13]
So unofficially, you can store anything in context. And especially in just practical use cases, I love using maps and sets and custom data structures, things that are not really directly serializable. So serializability is really important for when you're actually using developer tooling. So that you can take that initial context and you can present it in a way where you can ship it as JSON or maybe even converted to SC XML somewhere.

[00:06:49]
And these target locations really don't have a way of understanding a map or a set because there's no way to serialize them cleanly. However with xstate inspect, we are coming up with a new way to serialize custom context. So even if you have custom data structures like maps and sets you should be able to tell the serializer, I want to serialize these in this specific way.

[00:07:20]
So that in the developer tooling, it's shown either as null or as just the string map, or just as a custom data structure that is serializable and that you can understand in the developer tooling. So in short, put whatever you want into context, but just keep in mind when you're using developer tools, that machine definition is sent over the wire to whatever inspector you're using.

[00:07:46]
And it needs to show that somehow, and obviously JSON and JSON serializable things are the easiest way for the inspector to do that. Today, we covered a lot. We talked about software modelling event driven architecture, and the why behind using state machines and state charts to describe your application logic.

[00:08:08]
We went over the fundamental parts of state machines and state charts and how to use them effectively in your application logic, especially to improve it in a natural way and an easily visualizable way. We also talked about the actor model and how it's important to conceptually view your app as different actors talking to each other, just for a proper separation of concerns.

[00:08:35]
And we talked about other topics as well, such as using state machines for things other than implementing your application logic like testing your app. And just some developer tooling that you can use to make state machines that much more useful in your application. I hope that you surmounted the learning curve of XState and learned about state machines and state charts and how useful they could be in your application.

[00:09:02]
And I wanna thank you all for joining this workshop.