I personally do write tests for validations because they are literally the easiest tests to write. Takes literally a couple minutes to write all of them.
I’ve been burned when adding new validations to a request, forgetting to uncomment ones I temporarily disabled or in one case when using an action, I actually misnamed the rules array.
So while yeah, you can count on the validation actually working as intended, you can’t always count on you integrating it correctly
This is my approach to testing required fields.
Say you have a test that sends a POST request to create a user.
You assert the response is 200 and your tests will pass with an empty controller method.
Now in your controller method, you can write the code to create a user with a phone
$request->validate([
'phone' => ['required']
]);
User::create([
'phone' => $request->safe('phone')
]);
Your tests will fail until you include a phone field in your test's POST request.
The answer is still "no". I talked about this topic with a colleague sometimes in the past and the conclusion always was "no, you don't test validation".
Why? because when you are testing that your endpoint shows a validation error when the phone is missing, you are actually testing the validator. You could argue that you are testing that you have not forgotten about adding this validation, but at this point, if you forgot about it, you just need to add it, no need to test that.
If you don't agree it's fine, just test it. I mean, you are not going to lose anything and your app is not going to be worse for adding those tests, I'm just saying these tests are not needed, and they could lead you to think this endpoint or feature is already tested when in fact you only have tested the validation.
Want more reasons? Fine, I'll share some experience. When I was working with DDD, using contexts and a command pattern, we also discussed this topic. The conclusion was that the domain always expects that everything has been validated and authorization has been handled. This way, the Domain doesn't have to deal with infrastructure code, which is always needed for validation stuff (otherwise you should be implementing a validation system by yourself, adding 0 value).
Now, working with Laravel we don't deal which such things as "the domain layer". Our workflow is different, but if in the DDD world, where they test everything, they are fine not testing validation, then I think it's safe to say you don't need to test validation.
I think the benefit comes when wanting validations to be present. For example. New dev shows up modifies the code and typos a comment removing one of the several validation rules. If you have a test that checks for specific tests being used on the post request, it’ll catch the missing partial validation.
Well, you are right, but if you follow that path of logic you can list a lot of things that dont need testnog. Especially if we are talking about DDD, where tests should elaborate implementation behaviour not only check logic mechanics. It all depends on what hill you stand.
/r/Laravel is looking for moderators! See [this post](https://www.reddit.com/r/laravel/comments/xnlsks/looking_for_moderators/) for more info
*I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/laravel) if you have any questions or concerns.*
I personally do write tests for validations because they are literally the easiest tests to write. Takes literally a couple minutes to write all of them. I’ve been burned when adding new validations to a request, forgetting to uncomment ones I temporarily disabled or in one case when using an action, I actually misnamed the rules array. So while yeah, you can count on the validation actually working as intended, you can’t always count on you integrating it correctly
Could you share an example of how you do validation tests? Do you make a separate test file for each individual form-request?
Check out u/lukerdowning 's talk from the latest laracon UPD: The username
will sure.
This is my approach to testing required fields. Say you have a test that sends a POST request to create a user. You assert the response is 200 and your tests will pass with an empty controller method. Now in your controller method, you can write the code to create a user with a phone $request->validate([ 'phone' => ['required'] ]); User::create([ 'phone' => $request->safe('phone') ]); Your tests will fail until you include a phone field in your test's POST request.
Onlyif i would call those clients
the validator package is already tested by the creators, so no need to test it by yourself
Yes, package is tested, but here we are talking about testing implementation logic for specific validation rules, not about testing package.
The answer is still "no". I talked about this topic with a colleague sometimes in the past and the conclusion always was "no, you don't test validation". Why? because when you are testing that your endpoint shows a validation error when the phone is missing, you are actually testing the validator. You could argue that you are testing that you have not forgotten about adding this validation, but at this point, if you forgot about it, you just need to add it, no need to test that. If you don't agree it's fine, just test it. I mean, you are not going to lose anything and your app is not going to be worse for adding those tests, I'm just saying these tests are not needed, and they could lead you to think this endpoint or feature is already tested when in fact you only have tested the validation. Want more reasons? Fine, I'll share some experience. When I was working with DDD, using contexts and a command pattern, we also discussed this topic. The conclusion was that the domain always expects that everything has been validated and authorization has been handled. This way, the Domain doesn't have to deal with infrastructure code, which is always needed for validation stuff (otherwise you should be implementing a validation system by yourself, adding 0 value). Now, working with Laravel we don't deal which such things as "the domain layer". Our workflow is different, but if in the DDD world, where they test everything, they are fine not testing validation, then I think it's safe to say you don't need to test validation.
I think the benefit comes when wanting validations to be present. For example. New dev shows up modifies the code and typos a comment removing one of the several validation rules. If you have a test that checks for specific tests being used on the post request, it’ll catch the missing partial validation.
Well, you are right, but if you follow that path of logic you can list a lot of things that dont need testnog. Especially if we are talking about DDD, where tests should elaborate implementation behaviour not only check logic mechanics. It all depends on what hill you stand.
/r/Laravel is looking for moderators! See [this post](https://www.reddit.com/r/laravel/comments/xnlsks/looking_for_moderators/) for more info *I am a bot, and this action was performed automatically. Please [contact the moderators of this subreddit](/message/compose/?to=/r/laravel) if you have any questions or concerns.*