It's been 8 years since I started working with Laravel, leading a team of senior developers and now running my own SAAS business built on Laravel. Still, when I see a new Laravel-related video, especially from its maintainers, it gives me a next level of satisfaction. Thank you so much, Laravel team, for building and maintaining this amazing framework. ❤❤❤❤❤❤❤❤❤❤❤
I've got a master in applied statistics and one of the first things a professor said in my first statistics class when another student asked him about a simple significance test was "I don't know".
thanks for this Josh, not nearly enough is said of testing and seeing your fresh take on Laravel testing is most welcome. Your approach is a good one in that your helping all to use tests and in a way that is encouraging and uncomplicated, so we all need to do tests now 🚀🚀
I love testing. Allthough im often falling into the pithole of "i quickly need to write that feature, ill test it later" cause im kinda in the need of delivering fast often. I think even with taking the extra time of writing the tests it probably often would even save time but i dont actually know. Do you guys know that mindset and have you broken that cycle? And if so how? I find myself very often I a bug situation later on where i think "If i only had written a test back then, that wouldn't have happen"
Hopefully others can chime in, but I can say as someone who now wants to write tests for features I have written in the past, I think testing is a great way to get you to stop and think about what a particular page/feature/components needs to be able to do before you even test it on the page. I think that's going to be my approach from now on: - Write the Livewire logic - Write a test - Write the front-end - Test it from the UI But... I'm still learning. :) -Josh
Yes, that heppens to me a lot as well. I also really don't like the TDD approach because it feels so backwards and you often don't know exactly how the solution should work before you start. I find that unit tests are usually not really needed and can often be a waste of time. I prefer feature tests and E2E testing in most cases. Unit tests are great for some critical parts of the application where it needs to be exactly right. For example price calculations or payment flows.
If you fully write the feature, you'll never write the test. For one, you've "done" your work, so a test now feels like a waste of effort. Secondly, because you already implemented the code, you know too much and will end up polluting your test with implementation details that it shouldn't know about; making it a bad test. you need to go somewhat 50-50. 1. Write the first few high level abstractions of the code and its flow. You're not writing any implementation details yet, just what input/outputs and functions are being called. 2. Identify the critical paths you need to test for in the code (You might not need to test everything) 3. Write the tests, they should all fail because none of the code for it actually exists yet. 4. Start writing the code, starting from unit test level up to the feature level. This way is far more natural than the strict TDD approach. You've already mapped out the shape/flow of your code, then now you're using tests to ensure that when you implement it, you don't miss or f`k up anything else.
I'm also new to phpunit test. If you're going to do some refactoring from your old module, will you just modify your old feature test or create a new feature test and delete the old feature test?
I tried to apply testing also but seems I have to fight the framework to make tests like other teams in my company do :( They're pretty much mocking every every thing in the framework from model , eloquent , the query builder etc. Not sure if these tests are correct but feels like a pain in the arse to write tests like this. Sure you can also make a test sqlite but I feel this is not the correct way to "unit test" ... I dove down deep the rabbit hole and things got very very academical and complex to the point I gave up. Apparently you can do something like a repository pattern and build on top of the laravel model and that makes it easier to unit test but I have no idea how. Every tutorial or article barely scratches the surface of this. I need a concrete actual good practice example which I couldn't find for the past 2-3 years.
I always thinking about every possible scenario to testing and I never can say "it's enough" and it ends with "ok, i'lll do tests later" (yeah, sure...) :(
See, my previous thoughts were always along the lines of, "It's just me so I don't need to do them. :)" Boy was I wrong. Testing could have saved me tons of time in some scenarios. -Josh
It's a play on Jest (the testing framework for JavaScript), but for PHP. "PHP Jest" -> Pest PHP, Pest. OfferZen made a video about it, feat Nuno himself: th-cam.com/video/TdtJluPnl6E/w-d-xo.html
They prefer errors in production and developers spending even more time with manual testing? The clients are not always right, especially not in our field. As the expert you need to tell them what is best.
I agree with @@Pekz00r here. It's your choice, not theirs. It's your value that you can give to them. If they don't want that value, you have to make sure they understand the higher possibility of future follow-ups and (far) more costs to come when it ultimately fails. It's not only a fail-save for you, but also for them.
Disagree. It might seem cost-effective to wait for errors to appear, this can lead to larger issues down the line, such as unexpected downtime, loss of data, or compromised security.
I think in addition to what has been mentioned above, once a team has a flow for testing and creating features, you can build features faster too which the client is ALL for. :) -Josh
I would never mention tests to clients, either they hire me because they trust me to deliver a good project or not. If they explicitly state I'm not allowed to write tests, I'm not to be hired. Testing saves me time and doing TDD doesn't drain my brain as much with complex logic as when I'm not writing any tests. It's a safety net I'm building for myself to not introduce bugs when changing code later. Currently maintaining a code base and each day a failing tests saves me from introducing new bugs and unwanted behaviour when working on some new requirements.
![ปฏิเสธไม่ไหว (Crush on you) - LIPTA feat. No One Else [TEASER MV]](http://i.ytimg.com/vi/VC689EgdSIw/mqdefault.jpg)
It's been 8 years since I started working with Laravel, leading a team of senior developers and now running my own SAAS business built on Laravel. Still, when I see a new Laravel-related video, especially from its maintainers, it gives me a next level of satisfaction.
Thank you so much, Laravel team, for building and maintaining this amazing framework.
❤❤❤❤❤❤❤❤❤❤❤
That's an incredible journey. Thank you for sharing. :) Keep up the great work!
-Josh
I've got a master in applied statistics and one of the first things a professor said in my first statistics class when another student asked him about a simple significance test was "I don't know".
Sounds like a professor I would have loved! :)
-Josh
A teacher to acknowledge that he doesn't know something, is better than one that doesn't (:
thanks for this Josh, not nearly enough is said of testing and seeing your fresh take on Laravel testing is most welcome. Your approach is a good one in that your helping all to use tests and in a way that is encouraging and uncomplicated, so we all need to do tests now 🚀🚀
So glad that this was helpful Jon. I've already written more tests since this video! ☺️
-Josh
i started watching you for laravel but you saying you never tested in Laravel just makes me more intrigued lol to learn so you got me hooked lol
I'll take it. 😂
-Josh
I started learning testing yesterday, from the Laravel docs 😁
Hey me too! :)
-Josh
This is really good. Too often our industry just feigns competence in literally everything.
I'm glad you agree. I think there's a lot we all can learn when we realize that there's SO MUCH to learn. :)
-Josh
I love testing. Allthough im often falling into the pithole of "i quickly need to write that feature, ill test it later" cause im kinda in the need of delivering fast often. I think even with taking the extra time of writing the tests it probably often would even save time but i dont actually know. Do you guys know that mindset and have you broken that cycle? And if so how? I find myself very often I a bug situation later on where i think "If i only had written a test back then, that wouldn't have happen"
Hopefully others can chime in, but I can say as someone who now wants to write tests for features I have written in the past, I think testing is a great way to get you to stop and think about what a particular page/feature/components needs to be able to do before you even test it on the page.
I think that's going to be my approach from now on:
- Write the Livewire logic
- Write a test
- Write the front-end
- Test it from the UI
But... I'm still learning. :)
-Josh
Yes, that heppens to me a lot as well. I also really don't like the TDD approach because it feels so backwards and you often don't know exactly how the solution should work before you start.
I find that unit tests are usually not really needed and can often be a waste of time. I prefer feature tests and E2E testing in most cases. Unit tests are great for some critical parts of the application where it needs to be exactly right. For example price calculations or payment flows.
If you fully write the feature, you'll never write the test. For one, you've "done" your work, so a test now feels like a waste of effort. Secondly, because you already implemented the code, you know too much and will end up polluting your test with implementation details that it shouldn't know about; making it a bad test.
you need to go somewhat 50-50.
1. Write the first few high level abstractions of the code and its flow. You're not writing any implementation details yet, just what input/outputs and functions are being called.
2. Identify the critical paths you need to test for in the code (You might not need to test everything)
3. Write the tests, they should all fail because none of the code for it actually exists yet.
4. Start writing the code, starting from unit test level up to the feature level.
This way is far more natural than the strict TDD approach. You've already mapped out the shape/flow of your code, then now you're using tests to ensure that when you implement it, you don't miss or f`k up anything else.
I love your videos, it's always so interesting. Keep it up! :)
Can you tell which theme and icon theme you are using in vs code?
i second this!
Thank you for the support! :) This is the Catppuccin Frappe theme and icon theme in VS Code.
-Josh
I'm also new to phpunit test. If you're going to do some refactoring from your old module, will you just modify your old feature test or create a new feature test and delete the old feature test?
I think you can just modify your old feature test. But it might be helpful to have them up side by side since that way you know one works. :)
-Josh
Which code editor is it? Looks lot simpler to be VS code
This IS actually VS Code. :) I have a video on my personal channel of how I set it up and some of the configuration.
-Josh
Nicee! Thx!
Thanks for learning with me. :)
-Josh
Thanks
Thanks for watching. :)
-Josh
I tried to apply testing also but seems I have to fight the framework to make tests like other teams in my company do :(
They're pretty much mocking every every thing in the framework from model , eloquent , the query builder etc. Not sure if these tests are correct but feels like a pain in the arse to write tests like this. Sure you can also make a test sqlite but I feel this is not the correct way to "unit test" ... I dove down deep the rabbit hole and things got very very academical and complex to the point I gave up. Apparently you can do something like a repository pattern and build on top of the laravel model and that makes it easier to unit test but I have no idea how. Every tutorial or article barely scratches the surface of this. I need a concrete actual good practice example which I couldn't find for the past 2-3 years.
I always thinking about every possible scenario to testing and I never can say "it's enough" and it ends with "ok, i'lll do tests later" (yeah, sure...) :(
See, my previous thoughts were always along the lines of, "It's just me so I don't need to do them. :)" Boy was I wrong. Testing could have saved me tons of time in some scenarios.
-Josh
Can you please share your vacode config?
Theme
Font
Icon theme
This is the Catppuccin Frappe theme and Icon theme. And then Dank Mono for the font. :)
-Josh
@@LaravelPHPthank you so much ❤
brb 9:40
Second
👋 Glad to have you here to watch the testing newbie. ;D
-Josh
Fun fact: Pest is the german word for plague. Maybe testing is just that?
Uh oh. 👀
-Josh
Yes, same in Swedish. It is pretty weird.
It's a play on Jest (the testing framework for JavaScript), but for PHP. "PHP Jest" -> Pest PHP, Pest.
OfferZen made a video about it, feat Nuno himself: th-cam.com/video/TdtJluPnl6E/w-d-xo.html
Real men test in production
Not me anymore. 😁
-Josh
Clients don't want to pay extra for testing; it's usually better to wait for the error to appear.
They prefer errors in production and developers spending even more time with manual testing?
The clients are not always right, especially not in our field. As the expert you need to tell them what is best.
I agree with @@Pekz00r here.
It's your choice, not theirs. It's your value that you can give to them. If they don't want that value, you have to make sure they understand the higher possibility of future follow-ups and (far) more costs to come when it ultimately fails. It's not only a fail-save for you, but also for them.
Disagree. It might seem cost-effective to wait for errors to appear, this can lead to larger issues down the line, such as unexpected downtime, loss of data, or compromised security.
I think in addition to what has been mentioned above, once a team has a flow for testing and creating features, you can build features faster too which the client is ALL for. :)
-Josh
I would never mention tests to clients, either they hire me because they trust me to deliver a good project or not. If they explicitly state I'm not allowed to write tests, I'm not to be hired. Testing saves me time and doing TDD doesn't drain my brain as much with complex logic as when I'm not writing any tests. It's a safety net I'm building for myself to not introduce bugs when changing code later. Currently maintaining a code base and each day a failing tests saves me from introducing new bugs and unwanted behaviour when working on some new requirements.
First
👋 :)
-Josh