Laravel validation

Victor Gonzalez
A free video tutorial from Victor Gonzalez
Senior Web Developer
4.5 instructor rating • 2 courses • 3,846 students

Lecture description

Now that we have the basic test working, let's explore how to perform validation to our project.

In this episode, we cover:

  • Adding other fields to contact model

  • Writing validation tests

Learn more from the full course

Laravel API Development & Vue JS SPA from Scratch

Learn how to develop a robust API with Laravel and a Single-Page Application in Vue JS from Scratch

05:38:27 of on-demand video • Updated July 2019

  • RESTful API Development with Laravel
  • Vue JS Single Page Application Methodology
  • Front-End Design Using Tailwind CSS
  • Implementing Search Functionality Using Laravel Scout
  • Build a Complete SPA from Scratch
English [Auto] Now that we have our basic test working for adding in new contact to our application let's take it a step further. So let's pull open our features test and then open the contacts test one more time and let's go ahead and add some more fields of course the name is not the only thing that we need to store. So let's go ahead and add a couple of other fields. So at the very minimum a contact is going to need a name. They're going to need an email just add a test email dot com. They're also going to need a birthday. So we'll say birthday column is going to be equal to 0 5 14 1988. And I'm going to show you some cool stuff on how to do dates specifically how to turn them into carbon instances. Pretty cool stuff. Finally they're going to need a company that they're going to be associated with. And this is just simply going to be a string of a company we're just using this to have a couple of fields that we can play with. So if we ran this of course what else do we expect. But what are we fetch that contact instead. So let's say contact. Go ahead and fetch me that first one that is in the database. Now there is only one in the database. So of course this is going to be the same one that we just added. Because remember that refresh database gives us a clean database after every single test. So we can change this from contact all to just simply be contact and then let's go ahead and make some further assertions. Let's assert equals test. Name if we work to get the context. Nate also we expect test at email dot com. If we get their e-mail. So this is basically asserting that we received all of the appropriate data back from our database the same birthday. And finally ABC string is gonna be the company name so we'll change that to company. All right let's go ahead and run our test with these changes and then we get the first error assert count meaning I couldn't assert the count because it is not countable. Of course when you run count first what returns back is not a collection anymore. So we can actually safely remove this altogether because if this passes we actually don't need this line anymore. So let's get rid of it altogether. Let's run our test again. OK. We failed asserting that no matches the expected test. And this is for a couple of different reasons. It's at this line right here. Of course there is no e-mail field in our database and we are also not saving this into our database. So what do we do that now. Let's start with the migration. So let's go to the create context table and we're gonna need a new string for e-mail and we know we're gonna need a new string for birthday and then we're gonna need a new string for company then inside our controller context controller. We're also going to have to do something very similar so name email and then birthday and company. OK let's run our tests now and we're back to green. Great. So we are taking care of adding each of these fields and mapping them to the appropriate place. But we're still not doing any validation at all. As a matter of fact if we were to actually send this in with only test name it should fail. So what do we make a test to prove that that does not work yet. So let's say a name is required. Now we're going to copy a lot of this setup here and then we're going to do a refactor to show you how to clean this test up a little bit. So if we were to post and simply omit the name what do I expect here. I expected to be a validation error for this post. So let's go ahead and save this response and then we can assert on that response. So let's say response a search session has errors for the because we expect it to be a validation error. So what else can we test. Well we can also test that no contact got added to our database. We could do that. But simply saying this a search count of zero inside our contacts table when we fetch all of the records. Does that make sense. So if we were to post this and we get a validation error. Well there should not be anything inside our database. Fair enough. All right. So let's go ahead and run this test. So BHP unit dash dash filter and then we'll just filter this to this one test. Now scrolling back up reveals that we have an integrity constraint violation. Basically we got all the way through and tried to actually insert this record in our database. But of course our database said wait a minute that name field is required and you didn't pass in any data for name. So of course we know this is because we're not doing any sort of validation. So let's take care of that now. Let's go into our controller and let's go ahead and start validating our data. So let's say data is equal to request validate and then validate of course is going to take an array. There's always gonna take the shape of each of the fields that we're trying to validate and they're each going to have a set of rules. So we can actually copy this array right here and we'll modify it. So instead of request all of that let's just get rid of this altogether and just simply put empty strings for now and instead of passing it in a right to here we'll pass in data data of course is coming from this that we're saving right here. So the requests validate returns an array of data that has been validated. So that's pretty cool. All right. So let's go back here run our test again and we should get the exact same error because yes we are validating but we haven't told Lavelle that the name is required. So let's do that now. So the name is required to run our test again. And now it says the given data is invalid. We're getting the validation exception. However the reason why the test is not passing is because we have exception handling turned off yet we are kind of depending on it. So when we remove this top line here and run our test again and sure enough we are at Green. Awesome. All right let's do another one for email now. So the email is required. So a new test e-mail is required very basic setup as this except that this time we will have a name but no e-mail. We'll just say test name. OK let's run this test instead. Peach four unit dash dash filled and sure enough we failed asserting that there was a key for error. Of course we're not doing much in terms of the email being required. Let's go ahead and hit required on that. Let's go back here and run our test again and we get failed asserting that the name is missing. We must have made a mistake here. Of course we forgot to change from name to email. E-mails the one that we're actually trying to validate. So let's run that test again and sure enough it's back to green. Let's run all of the tests and although the tests are also passing so as you're starting to see this is starting to get a little bit repetitive. So why don't we take a couple of minutes to refactor this code to be less repetitive.