Coverage of Unit Tests in Laravel

Question

Coverage of Unit Tests in Laravel

Navigation

#1 by (2 votes)

1

When starting a repository with a new Laravel 5.5 installation and configuring the test coverage and Coveralls for this, even though you have only done scaffolding of the framework authentication and have not written a single line of code, the return is which has only 33.33% of test coverage with the following report:

Found 13 source files:

100.00% app / Console / Kernel.php
0.00% app / Exceptions / Handler.php
0.00% app / Http / Controllers / Auth / ForgotPasswordController.php
0.00% app / Http / Controllers / Auth / LoginController.php
0.00% app / Http / Controllers / Auth / RegisterController.php
0.00% app / Http / Controllers / Auth / ResetPasswordController.php
0.00% app / Http / Controllers / HomeController.php
0.00% app / Http / Middleware / RedirectIfAuthenticated.php
100.00% app / Providers / AppServiceProvider.php
100.00% app / Providers / AuthServiceProvider.php
0.00% app / Providers / BroadcastServiceProvider.php
100.00% app / Providers / EventServiceProvider.php
100.00% app / Providers / RouteServiceProvider.php Coverage: 33.33% (24/72)

All of these classes should probably be testing coverage in the framework repository. The question would be, should I do the unit tests for all these classes not covered in my own test suite or do I seek to disable the testing coverage check for these classes? Mainly the framework itself as BroadcastServiceProvider, Handler, etc.?

link link

php laravel tdd phpunit

asked by anonymous 14.02.2018 / 17:31

1 answer

Mkdir creates directories without permission Query to return text from the middle of a field

score 2 · Accepted Answer

All of these classes should probably be covered by tests in the framework repository.

Probably, but be careful because these classes are meant to be customized for your project. If you add more code to them, it might be worth testing it if you feel it is necessary.

I must do the unit tests for all these classes not covered in my own test suite or try to disable verification of test coverage for these classes?

There is a decision for your project. Code coverage by unit testing is an interesting metric to evaluate code quality, but focusing on reaching 100% is not synonymous with quality.

In the case of your project, a single test that accesses home has already guaranteed a coverage of 33%. Excluding this type of test, which is not considered a unit test, project coverage drops to 0%.

Try to diversify the suite of automated tests, so that you have integration testing between components, acceptance testing of a stream as a whole, interacting as a user, and more.

In the case of Laravel, I like to leave the application logic entirely out of app , within a src directory, totally decoupled from the framework , and only generates coverage with unit tests of code in src . The rest I guarantee with other types of tests, such as acceptance and integration.

But again, it is a matter of application architecture and the team that must decide how the metrics will be applied.

The advice I get is: focus not only on having coverage, but also on diversifying your suite of tests. Coverage is just one of the possible metrics. If even with a coverage you do not trust your test suite, it will only be a wasted effort.

Mostly the framework itself as BroadcastServiceProvider, Handler, etc.?

From the moment you ran a composer create-project or laravel new , I consider that these files are no longer the responsibility of the framework , but rather your project. Here is the point above: Unitarily test if you have something worthwhile, not just to reach coverage .