[MUSIC] In this lecture, we will discuss devise account sign-up errors and the error payloads that come back so we can ready for our UI development. With sign-up complete, it's time to start the error path. If we take a look at their missing information and if we come up here and bring in, do a copy, and paste that in, the alarm bell should go off. Like, hey, creating an account that sure seems like it's going to be a reuseable thing. So why don't we instead of copying that and putting it there, why don't we go over to spec/support/api_helper and create a sign-up. Let's also check the status, but we're getting ready to do an error path, so we should allow them to supply an optional parameter. Okay, so if it's a failure case we want them to be able to tell that. Okay? So they're going to ask for registration. We'll do a post. We'll post the registration materials. We'll expect a specific status response back. Now I can go up here. Change that to signup user_props. It's going to default to okay. Let me rerun my successfully creates account test. That passes so it looks like this implementation is good to reuse. Okay, but it's going to be missing information. So, why don't we pass in instead of just user props, let's pass in user prompts minus email. And then let's supply a status code that's not non-positive. Okay, that's a good start. We're going to take a look at the payload. So our test passed because we're only looking for the failure to occur, and then we get a document back that tells us the status of our request. In the data is what it heard and the fact that we didn't supply it an email, and in the errors is the fact that we have some email issues going on. I kind of like this structure because think of it. If we can give this back to the UI and say in this field, that can't be blank, or in general, in this form, emails can't be blank. So I'm going to follow this kind of format, this kind of approach as we design out our other interfaces. Without going hog-wild, let's go in and put in a verification block and say that, okay, I am going to assert that what came back was an error in the document. That in the data they've told me that my email is not supplied, basically nil. That there's going to be some errors supplied, and the errors are going to tell me something about the email field, but I don't know what. Mia's writing the test, I don't know what it's going to say. And then in the full messages, it's going to say something. I don't know exactly what it's going to say, but it's going to say something about email. So, if I rerun that. [SOUND], that needed to be a regular expression. Let me change the quotes to a regular expression. And while I'm at it, let me not assert that they have a capital e but it could be a lowercase e. So now I'm saying that somewhere in the strings there will be the word email. Okay, that's looking good. We now have invalid registration as well as valid registration. And we have the startings of some helper methods, sign-up. That should be quite helpful when we come to this non-unique information. So based on everything we've covered, successful sign-up with user prompts, and unsuccessful sign-up with a missing email and an error message, you should be able to complete this last one. To be able to just turn this into a block out of the pending state, and verify that if someone supplies an email that's already been registered to an account that they'll receive an error. And that error should have some kind of indication that it's about the email address. So in summary, we took a look at account sign-up errors and the error reporting. And specifically the error payload, because we're going to have to communicate with this when we develop the UI. We notice that devise returns back the errors in sign-up in nice field format. You're missing a field, this one's an error, things like that, as well as full request messages, like your email is wrong, your name is missing. So on the UI, we have a choice of displaying things per field or at the overall form level. And then I left you with a practice to do. You should be able to complete the non-unique information example group. And look in your get repository if you have an issue. What's next? Authenticated Access Control. Wait, the build server discovered an error with our device setup, and we need to go fix that before we move on too much further. Like all normal developments, we can't plan our errors.