Write Tests. Generate UI. Profit!

Hi, everyone. Thanks for joining. My name is Ed Bentley. I'm a front-end developer. I mostly use React. You can catch me on Twitter. I'm also an indie game developer. This is my company Flute Games. We've got a new game coming out this year. So keep an eye out for that. I've also developed my own open-source JavaScript game engine called Replay. It's very much inspired by React. So, if you're interested in making games, I recommend you check it out.

But today I'm going to talk about tests. Now, generally when we're writing our apps, we write the app. And then we write the tests. Now, of course, if we're following test-driven development, then we might do this the other way around. For UI, I feel like we tend to do this way more. But I find it just, it takes up a lot of time. I was building my menu UIs the other day, and I really found it difficult to motivate myself to write the tests, after I'd already spent a long time writing all of the code. And if you think about it, we're duplicating a lot of the behavior. We're writing the app, and then we're writing the test again. And they're both got the same kind of behavior in them. So, I had an idea. I thought, what if you could just write the tests, wave some sort of magic wand, and then out of a chest appears your app.

Now, taking it seriously for a second, if I wrote some tests as code and handed that to you, you could probably then write the app itself, based on reading the tests. But what if a program could do that for you? You just write the tests, and then the program is able to generate the app for you. Now, I've taken this idea and I've built a library called Spectate. Now I want to show you Spectate today, and I've got a live demo. So, here I've just got a very simple React app.

I'm using Vite. Shout out to Vite. And at the moment, it's just saying, Hello, world. So, what I plan to build is an email signup form using Spectate. Now, we still write out the markup in React, and Spectate is just going to be like our state manager, so everything we're doing in React is just purely functional.

So, I'm going to start off with an email label and its input. Now, this is not going to be the most semantically correct HTML or following best practices, like we're not using a form. I'm just writing it as simple as I can to be as concise as possible today. We could also have a password input. And then we want a button to sign up with, sign up button. Okay. I've already done some styling here. So this is basically what it's going to look like. But right now it doesn't do anything.

So to add this behavior, we're going to write some tests. So we call it a spec. So I'm going to write myspec is equal to, and there's a function whose argument is new spec. The type of this is new spec. So you can use this if you're using TypeScript, it will help you with auto complete. And then we're going to define a new test, kind of like we write test with jest. We're going to write new spec and then a description. So what we're going to say is we can sign up with email and password. Now, it's going to be some helpful functions here. I know what we need ahead of time. It's going to be click on end text, do effect and equals.

So what we're going to do, we think about this email form for a second, we want to add an email address, add a password and then click on sign up. So what we're going to need is an input, so we can call this email input and we use the new input. We also need some text to store what we put into the input, so we're going to call that email text and this is a text variable. Now this input is connected to our text variable, so to do that, to show it's connected, we're just going to pass it in here. I'm going to copy this and do the same for password.

So now we have a password text and of course we also have the sign out button.

Okay, we've defined those, we also need to return them so that spectate can use them. So I'm going to return email text, email input, password text, password input, and sign out button.

Okay, great. Now let's write this test. Let's think about this for a second. First, what we're going to do, we're going to click on the input and this reads just like something like React Testing Library, which is a great library, shout out to that. So we're going to click on the email input and then we're going to enter text and we're going to write some sort of email, hi at test.com. Then we're going to click on the password input and then we're going to enter some sort of password and then we click on the sign out button.

Now, we've described this behavior, but what are we actually doing when we click on the sign up button? For the purposes of this demo i'm just going to log to the console. So to do that we need to create an effect. Now this is called, let's call this postJson and we can use this new effect which takes a function which just has our effects much like useEffect. You can see where i got the inspiration from. We're just gonna log post here.

Okay now going back to our test, when we click on the signup button we need to actually do the effect and the effect is postJson. Okay, that's that. Now we've actually got to put it into our app and there's a very simple API here. Our props are defined by a hook called useSpec. useSpec is imported from our library, spec.txt, and we pass in here our function we defined, mySpec. Okay now we look at props and we can see it's got all of the fields that we defined earlier in our function. So conveniently we can just spread the props. We have email input we can just spread the props of password input, and again spread the props of the signup button. And this is designed to be as simple as possible because really we're spending our time writing the tests and we don't actually have to spend much time writing the markup itself.

Okay I've got that, let's see what happens. I write an email, write a password, there we go, we've got a post. After we clicked on the signup button. Um, let's improve this a little bit. Firstly, I don't like how we can see the password, we need to change the input type. So here we can just say input type is password, but we still want it connected to the password text variable, so it knows which variable to update. The other thing I want to do is in our post, I want to actually get that email and password value we entered.

So I'm going to enter getval here, which this has an argument which we can use to get the value as a string of our variables. So we can say email text, we can get the value of our password text, just like that. You can see our input type has changed. We click sign up, and there we go. It's posting our email and our password. So this effect could be anything you want. It could be a fetch request. It could be a GraphQL request. The effect is here and it's called by our sign-up button.

Okay, this is great, but we have a problem. If we don't have a password or email, it's still trying to send a post request. What we want is it to tell the user, oh, you've got an empty email. So how do we handle this case? We just write another test case. So let's define it. We have a new spec. Now we want to say, shows error if it's an empty email. Again, we want to get this click on and equals, so in this case, we haven't interacted with the form elements at all. We're just going straight to click on send our button, because there's no email, there's no password. And then there's going to be an action after it. Now we're going to need to add some extra text to give us a helpful error message. So I'm going to here define error text. Like that. And then we say after this sign up button is being clicked on, our error text is going to equal, hey, email can't be empty. And just for completeness here, after you've signed up successfully, I'm going to say that the error text is an empty string, just to clear that. Lastly, we just need to show the error text in the app. And we have to go back to our React markup here. So we can say props. And of course, don't forget, we need to return this text variable from the function, so that we can use it with React as a prop. So we have our error text. And then we have a span, which I have for some sliding here.

Error, and its value is just going to be the error text itself.

Okay, let's give it a try. Click sign up. Tells me email can't be empty. Okay. I'm going to add an email. Ah, it's giving me a warning, because Spectate doesn't know what to do in this case. Should I show you a warning about your email? Should I post in json? I don't know. What we want it to say is, you have an empty password. So how do we handle this? We add another test case. So I'm just going to copy what we had before. But this time it shows an error for an empty password. Now, I'm going to copy this email input from earlier because in this case, we've already entered an email. But then we click on the sign-up button. Like this. So we've clicked on the email input. We've entered some text. And then we clicked on the sign-up button. And then we show the error text is, password can't be empty. Okay, let's give this a try. Great, password can't be empty. Now we add our password. And it posts. And again, if we clear it, it still shows the email error message, not the password error message. Okay, and that's an example of how you can build an email sign-up form using Spectate. You can see we don't need to write any tests. We've written the tests. And the tests themselves have generated the kind of app logic, the app behavior. And this is it. And you can use these as building blocks to really build up more complicated apps.

There are more things like lists that we haven't covered today. But that really is the gist of what Spectate can do.

Now, you may be thinking, this is a lot of magic. I don't really understand how this works. And magic is generally bad for us developers. So I'm going to try and explain how Spectate is working in this case.

So we take our first spec. And as it said, it can sign up with an email and password. So what we're going to do is, when the app first loads, Spectate is going to run through all of your specs. And it's going to simulate them, and it's going to build up a model based on them.

So let's imagine we're building up this model. We're starting with our own internal state on the left. This internal state is defined by the variables that we defined in the spec function. So we created an email text with new text. We created a password text, and we created an error text. So this internal state has started with all of the strings as just empty values.

Now, we also have this focus field. This is just going to be empty, because nothing's focused at the moment. But this is looking at what the browser is focused on.

Now let's run through the spec. We clicked on the email input. So our focus is now on the email input. Then we clicked on we enter text. So we've updated our email text. The input is focused. The input was connected to the text. So the text value has now been updated. Then we click on password input, and that's changed the focus to the password input. And then we've entered the text password. Now this is the critical step.

We clicked on the sign up button. Now we're not going to actually run what happens after the sign up button in that red box. We're just going to save that. And we're going to look at the state currently. And we're just going to pop this into our model. So we've saved.

Okay, when the app was in this state, we did these effects this effect and this equals. And then we're going to move on to the next step. So in this case, it was showing an error. If there's an empty email, we start again with an empty state. We've clicked on the sign up button. And that's gone straight into an action. So we just put that back into the model. Again, we've got this state and the actions that followed it at that state. And the final case, which was when there was an empty password. Clicked on the email input, again, focus the email input. We entered some text to have some email text. Clicked on the sign up button. We look at the state when we clicked on the button and the actions that preceded it, that followed it. And then we put those into the model.

Okay, now we've built up a model. Now imagine we're actually using this app for real as a user. Now we're going to start with an internal state again that's going to be tracked as you're using the app. We can see the app here. Now let's think about it. What happens if you click on the sign up button? What spectator is going to do is it's going to look through the model and it's going to say, where is the state now, most similar to a case I saw before in the model. So it's going to select this case where all of the state fields were empty. And then it's going to run those actions, so it's going to set the error text to email can't be empty, essentially a set state. And then we see visually email can't be empty. How about the next case when we had entered an email? Now you'll notice that here email text is a string hello at gmail.com.

But in our model the most similar one was this case where we had hi at test.com. Now, Spectate doesn't compare exact values for strings. It's just going to look at is the string empty or not? It's not perfect, but it actually is great for a lot of cases. So we're looking here. This is certainly in the most similar state because password text is empty, error text is empty, and email text is not empty. So we choose the action here, equals error text, which happens to be password can't be empty. And then we see that on the screen.

Now, the final case, what happens when we've filled in both fields? I think you can probably guess this by now. We've got an email text, we've got a password text. So it's going to select this state in the model, and then it's going to take those actions and run them. And so we end up posting the email and the password.

Okay, that's Spectate. You can find it on GitHub. It's an open source project. The last thing I want to do is just show you some more examples of what it can do. So here is a live demo website. It's linked to on the GitHub page. So do check it out. You can see some examples of what you can build. There's the customary to-do app, which every state manager I think has to do. So you can say, feed the cat, water the plants. And we can tick these to-do off as they're completed. And this is all written with Spectate. And you can view all of the code here. I thank you for listening to me. I hope this has aroused some curiosity to check it out. This is an entirely new way of building UIs. Do check it out and play around with it and see what you can build. And again, you can catch me on Twitter.