Do you write tests for small web apps or only for mid/large systems?
@bor1904 Why do you think you would only write tests for “mid” or “large” systems? Is a “small” app not worthy of being tested? Do you not care if a “small” app works or not?
Testing is exactly that: testing something works. It makes no claims about how “big” an app has to be before it warrants testing. You write tests if you want to be sure the code you’re writing works, and you omit them if you’re not bothered.
Always phpunit or always dusk? Or it depends?
Personally, PHPUnit-based tests. I’ll write feature tests that essentially make HTTP requests and then make assertions on the responses, i.e. whether I’m expecting a successful response or say, validation errors if I intentionally submit incorrect data.
I’ll then create another tests/Integration directory and put tests in their that test the actual classes of my application. So things like service classes, jobs, etc. Classes that I can test together but without invoking them through a HTTP request or CLI command.
I write very little unit tests as I find feature and integration tests give me enough coverage. I also can’t remember the last time I used Dusk. I’d maybe use it if I was doing a lot of UI-heavy work, but find it slow and would probably use something else for automated browser testing like Cypress if I needed to do these types of tests.
Do you develop your projects in TDD or usually you write test after coding?
TDD is nice, but never works in practice for me. It can work for feature tests where you know you want an endpoint to receive some data and return a particular response and then you can use your test to drive the implementation, but I find it impossible to do TDD at the unit level, as you kinda need to already know the code you’re writing ahead of time to be able to write granular tests like that.
So I’ll add tests as I code. I’ll get something working, as I may go through several iterations of renaming things the more code I write. Once I get something tangible (i.e. a controller action that does something) then I’ll write a test for that.
You normaly cover whole app by tests or only critical area/flow?
I cover the parts I need covered and want to be confident work. Too many people chase 100% code coverage but then you ended up testing useless things like the HTTP kernel class or form request classes, and end up with tests for the sake of tests. Why are you ever going to use a form request classes on its own? You wouldn’t. So its logic would be covered by the feature test for the controller that makes use of it. That request class is then covered by that test; no need to write a separate “unit” test for that form request class.
As mentioned above, I’ll also test validation by intentionally passing invalid data to endpoints. So omitting fields that are required, passing out-of-range values for things like min and max rules, etc. This can obviously get laborious quickly, so you can use PHPUnit data providers to simplify these tests:
public function testFieldIsRequired(string $field): void
{
$data = [
'headline' => 'Test Headline',
'summary' => 'Test summary.',
'body' => 'Test body.',
];
// Remove the required field
Arr::forget($data, $field);
$response = $this->post('/articles', $data);
// Assert validation failure for given field
$response-> assertSessionHasErrors($field);
}
public function requiredFieldsDataProvider(): array
{
return [
'headline' => ['headline'],
'summary' => ['summary'],
'body' => ['body'],
];
}
Do you write unit or future tests more often? Or always both?
I pretty much covered this above.
I start long project In small team and havent too mach practical knowladge about todays best practices in this area.
The crux is, you can get quite far with feature tests. Start with feature tests, make HTTP requests to your application and then assert the side effects. Check models were created that you expect to be created; check expected validation errors are thrown when you submit intentionally bad data; test queue jobs and mails are dispatched if they need be. This will quickly give you a lot of coverage and confidence in your applications. If you’re writing complicated business logic with lots of classes, you can then drop down to writing integration or unit tests that cover these classes in isolation.
