After talking about how to write tests, let's stop and talk about what to test.
The number one reason people don't write tests is time. They feel like they must write many tests, and it takes a lot of time to reach good code coverage.
People don't have enough time to write tests, which is ironic because they need to spend more time with each new feature testing, manually debugging, and fixing bugs that automated tests would otherwise catch.
In the long run, the argument "We don't have time to write tests" makes no logical sense.
The exception may be if your project is personal, with almost no users and only a few new features upcoming. Or, if you want to take risks and let your customers perform all the testing for you and report the bugs so you can fix them.
Side note: customers usually don't report bugs. They just leave bad reviews and move on to using other software in the future.
With that in mind, I assume that if you are reading this course, you want to do testing, and your goal is to write as many tests as possible. But hold on, it's not the goal.
Historically, this "code coverage" thing was really important and was emphasized by everyone that you need to achieve 100% code/test coverage. But let's look at it from a realistic perspective.
So, what is code coverage? Theoretical Wikipedia definition is "a percentage of which source code is executed when the test suite is run". What does it mean in practice?
The first example is from an article Generate Code Coverage Report in Laravel and make it 100% score easily. In this article, the author generates a code report in Laravel with Xdebug. So, you launch the test with test coverage, and it shows which of those methods were executed during the test being run.
The second example is passing the --coverage option to the php artisan test command. Before passing this option, the Xdebug should be configured. Then, after all the tests, you will see an output of your code coverage.
As you see, some files are covered 100%, and some are not. Now, do you want to achieve 100% test coverage? Not necessarily.
Point number one against the 100% test coverage is that even if you have 100%, you need to test the right things.
It guarantees the same method will be called, executed, and run during testing. But it doesn't ensure the correct assertions, all possible method parameters, and use cases. That code coverage report will not really prove that your test suite is good. It will confirm the number of tests. It may impress your boss or someone who cares about that number. It's better than nothing.
But, generally, I would have another goal in mind.
I will say it in one sentence.
Your first goal is to test the most critical parts of your application.
Search for the function that can cause you to lose your job if it breaks. Test that first. You could sleep better knowing that those crucial parts are covered.
If we go back to our product test example in the course, what would be the most critical features in our small demo project? The ones that, if they break, someone would potentially lose their job or the company would have a significant financial loss?
For example, you have a project to manage products, and what if the whole website is down? It means the project is not working, so the home page would not return status 200 with success. And interestingly enough, we don't have that covered by tests.
Another crucial part of the project is if someone can get unauthorized access to managing products. They may make some changes, delete some products or something like that. That would be crucial, right? So, authorization/authentication access should be tested early.
Also, anything related to payments or transactions should be covered as early as possible. If those features fail, someone will suffer from actual financial loss or even legal issues related to money.
So, in general, I think there are three things you need to test:
After that list, you may choose other features/units to test, optionally, if you have the time/budget.
So, from that point of view, writing tests shouldn't feel overwhelming. Start small. Add more tests later, feature by feature.