Good testing practices in Laravel projects?

Question

Test Driven Development

Please share your best practices for working with tests, especially when there are a lot of them. On structuring, naming tests, etc. The
question is perhaps outside the scope of Laravel.
Out of the box, the framework creates two directories: Feature and Unit.
Feature is something high-level. In the Laracasts video, Jeffrey Way calls them integration tests, someone calls them acceptance tests, somewhere they call them smoke tests. Everyone has their own approaches and the framework does not limit this.
Do you create subfolders in the Feature directory, such as Controllers, Endpoints, Jobs...
Do you use multiple asserts in your Feature (and Unit) tests, or break them up into different tests for readability?
How do you name unit tests?
Are you using camel-case or underscore?
Answers are desirable in more detail than: "It's a master's business. Do it as you like." It is so clear that it can be different.

Answer 1

Feature are end-to-end tests. You take the data, send it to the endpoint, and check the response/status of the task. From this it follows that there can be no sub-directories - at most one for the API, one for the Web, and, if you really want to, then one for the CLI. Such tests should NOT contain mocks, dependency spoofing, or anything else that interferes with the full testing of the endpoint from start to finish.
I usually write one for each endpoint, like GamesListTest for /api/games.
Unit - unit tests. Should test one class and mock other dependencies. Here you can test separately controllers, jobs, repositories, services and anything else that you want. All dependencies of these classes need to be replaced and the input arguments checked (as carefully as possible, mockery + hamcrest-php).
Also usually for a class test, it depends on the size of the class in question and the complexity of its methods.
I always use snake_case - it's more readable. assert'ov can be at least a million - I do not follow this at all. I break tests into methods purely according to logic and need - I do it as simple as possible. Personally, my tests are in "modules" and not in /tests, but the default structure is a good place to start.

Answer 2

For me, ideally, the structure of the unit folder is identical to src, in src there is a breakdown by functionality like /product /cart, etc., no Controllers/ and Models/ with a dump of all controllers, etc.