PHPUnit in Laravel: Simple Example of Why/How to Test
ฝัง
- เผยแพร่เมื่อ 8 พ.ค. 2020
- A video with a practical example, based on my another recent video: • PHP: Make If-Else More...
Here, I'm showing WHY we need unit-testing and how beneficial it is, in order to avoid bugs. Together, we write tests for existing feature, then refactor that feature, find a bug, and make sure that tests are working again.
My full course "Laravel: PHPUnit Testing for Beginners": bit.ly/phpunit-laravel
- - - - -
Try our Laravel QuickAdminPanel: bit.ly/quickadminpanel
Enroll in my Laravel courses: laraveldaily.teachable.com - แนวปฏิบัติและการใช้ชีวิต
![[TH] 2024 PMWC x EWC Main Tournament Day 1 | PUBG MOBILE WORLD CUP x ESPORTS WORLD CUP](http://i.ytimg.com/vi/f5Coja1zCzo/mqdefault.jpg)
The best laravel content on TH-cam
This is why you should always write your test before coding. Great work!
I usually go with the repository pattern, injecting a repository interface into the service and at the Unit test I use a mock of that to get data from the "database". According to Uncle Bob a Unit Test should be able to work either you have a database or not having one. Also by randomly generating data you can not be sure in every test what the outcome will be. Maybe works in this case but if you wanted to check the total amount of a period it would not work unless you insert specific data to test. Anyway, I really like your videos, there are very helpful.
Thanks for the comment, Thodoris. I agree with most of the things you mentioned - for bigger projects and more "correct" ways of testing I would do something differently, but I usually apply my videos to a certain audience. This time it's about people new about testing in general, so the goal is to "convert" them. And if in the same video, I mention interfaces/repositories/patterns and more complex mocking of the data (which all likely are new topics to them), I would lose them instantly.
So I often intentionally try to simplify my examples (sometimes to the point of making some illogical stuff for the long-term of that project), just to illustrate practical things for that specific topic.
@@PovilasKorop Just call it as 'integration' test, not 'unit'. 8)) Thanx for the video!
This is what I'm looking for, hoping to see more of these. Thanks, Laravel Daily for sharing your daily knowledge. Godbless.
It was one of the best I have seen till now. Thanx man. Good job
Great Work so simple and easy to be understood 🙌
Thankyou for making it simple and clear!
Thanks for the video. Waiting for more videos in this and services.
Awesome! Very well explained, thanks!
I learned so much from your channel! Thank you! Here's hoping I ace the Laravel coding challenge for a job im applying for.
Wow! Thank You! That was very informative
Wow, this is so informative and elaborate. Thanks!
Superb content. Thank you!
Perfect video. Thanks.
Thank you very much for great tutorial video!
it so simple and easy to be understood. nice video.
thank you sir.. this is really good and helpful tutorial
Nice example 👍
The real gold on TH-cam
Very nice tutorial
I like the way you teach
This was a good example... Loved it... Could you share the difference between Unit and Feature tests?? There is a lot of wrong asumptions out there.
I can't share it in a comment, I would advise probably to watch my course "Laravel: PHPUnit Testing for Beginners" - bit.ly/phpunit-laravel
I remember doing unit tests on sqlite and dev running on mysql
what css framework did you use for this lesson?
sir when we have to use unit tests?
what are benefit of using unit tests?
What is difference between unit and feature tests?
Hi Povilis. Do you know any "trick" to clone a database as you mention? I have a production database and I want to start testing with a clean database as you mention in the video! (I have no migrations as is a legacy project)
Not really, there's no such thing as "Cloning Full database" in PHPUnit, or at least I haven't done it this way. Maybe something like iseed may help you: th-cam.com/video/Qf1cs7MbHHs/w-d-xo.html
What do you think about PEST package and it's syntax? Some developers think that in future laravel versions it will be default test package
I do understand where it comes from and what are the benefits, but I prefer to stick to the "original" PHPUnit. Just for personal preference, I'm used to it.
Hi, I have a lot of code in my controller/index, which builds me a json api from all kinds of joined tables. Is there a way to assert if all the json data is provided, that is required by the frontend, and return some error if any of these json items aren't accessible? It would be easier to test like that rather than always swap between the frontend and the backend for errors. Thank you.
I can see 2 assertions you could do in your project.
Test case 1
Check if the "happy path" returns all data in json
Test case 2
Check if a given input with a wrong value returns an exception. Eg. Validation, not found, not authorized, not authenticated, etc.
How are tests are performing so fast ?
On my local it takes lots of time to load phpunit and then runs test
Please help
What about using .env.testing ?
in laravel 8 and phpunit 9.5.2 syntax factory(Model) not working. I must using Model::factory() - and its working fine.
Help!
I cannot access my imported classes within the tests.
I get: Error: Call to a member function connection() on null
is it ok to touch the database in unit tests?
It is ok, if you set up the testing database properly.
Now i know why unit testing is important
❤️❤️❤️❤️
why not artisan test
Because I want this video to be relevant also for those who use version previous than Laravel 7.
cool
Why are you opening folder ?
why everyone is using dark theme ?? I can barely see the text during the daylight
Great video, but it is painfully TIME CONSUMING to write that much code (unit test code) for a simple if else statement. What if we needed to do this for our WHOLE source code? I understand the advantages but is it worth the disadvantage? Maybe do this selectively?
I'm in the process of going back through a very large project and having to write the tests towards the end, due to sheer scale, shifting scope of the project, and time constraints. I would say even if you are not writing tests for every function, it's useful to think about the fundamental and most important parts of your codebase and how they should be tested, and note them into mock test/methods as you go. Going back through a large project cataloguing, identifying and implementing factories, tests, etc. is very time consuming indeed, but if it's critical business logic to be used in a production environment it's going to be more of a pain in the ass / time to support if you code is not operating a. on deployment, b. during normal business operation, because you did not write any tests to put your code to work in the first place.
I'm having a very hard time trying to understanding the difference between Unit tests and Feature/Integration tests, mainly in Laravel... Why is this a Unit tests and what would be an Integration test?
I wouldn't bother with naming: there's a Feature and a Unit test in Laravel. Integration is just a fancy naming of a Feature test, to simplify.
I've talked about it in my course: laraveldaily.teachable.com/p/laravel-testing-for-beginners-phpunit-and-pest
Writing unit test code seems more complicated and time consuming than writing the app code itself... And how can you be sure your unit test code is valid, are you going to write test code for your test code and so on? You surely can't rely on phpunit, and you still have to test your raw code anyway. The only true way to know if your code works is to run it, in my opinion.
It is an integration test, not the unit. In the unit test, you should not use a database or such. You should be able to mock the data source. If you'd do it using TDD, you'd write an empty class and then tests where you would call that class and not yet existing methods, inject class with existing dependencies that would be mocked for sourcing data and create data sets that would be generated or with faked data as you said. :-)
Unit tests should not test the database which is the case in this example...
But guess its preferences. Without the database layer, unit tests would run much faster because they wouldn't need to bootstrap the whole app to test a single function or class.
If you're using facades in functions you can be assured that this function cannot be unit tested, because the whole app container handler will have to be bootstrapped.
Basically, you cannot unit test as well controller actions. So all business logic should happen before controller action. So service should be injected to let's say repository and then service should be mocked to return dummy data for testing on required method calls.
Hello I'm Iranian We Can't Buy your courses(Because of sanctions) if you can have bitcoin pay in your site it will be excellent.
What is your suggestion for a scenario where I have to test a set of APis which have to pass through various middlewares (viz. jwt, roles and so on) and recaptcha... These APIs are supposed to call a service which eventually calls another set of external APIs (viz. google APIs) and the values returned by the external APIs are stored in the DB...
How do I go about testing that? Please advise.
Would really appreciate if you could cover this.