Coverage of Unit Tests in Laravel

Asked

Viewed 746 times

1

By starting a repository with a new Laravel 5.5 installation and setting up test coverage and Coveralls for this, despite having only scaffolded the framework authentication and not written a single line of code the return is that it has only 33.33% 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 covered by tests 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 seek to disable the testing coverage check for those classes? Mainly the framework itself as Broadcastserviceprovider, Handler, etc?

https://github.com/renanoliveira0/Where.is.My.Money https://coveralls.io/github/renanoliveira0/Where.is.My.Money

php laravel tdd phpunit

  • I do not believe it is necessary to test in these classes and taking advantage also do not believe that it is necessary to test in CRUD, in crud.

1 answer

2


All of these classes should probably be under test coverage in the framework repository.

Probably, but be careful because these classes aim to be customized for your project. If you add more code to them, it might be interesting to test it if you think it is necessary.

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

That’s a decision for your project. Code coverage by unit testing is an interesting metric for assessing code quality, but focusing on getting to 100% is not a synonym for quality.

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

Look to diversify the automated testing suite so you have integration testing between components, acceptance testing of a flow as a whole interacting as a user, and more.

In the case of Laravel, I like to leave the logic of the application entirely out of app, inside a directory src, totally uncoupled from framework, and only Gero the Coverage with unit code tests on src. The rest I guarantee with other types of tests such as acceptance and integration.

But again, it’s a question of application architecture and the team that should decide how the metric will be applied.

My advice is: not only focus on Overage, but also on diversifying your test suite. Coverage is only one of the possible metrics. If even with a Coverage High you do not trust your test suite, it will only be a wasted effort.

Mainly those of the framework itself as Broadcastserviceprovider, Handler, etc?

From the moment you executed one composer create-project or laravel new, I consider that these files are no longer the responsibility of the framework, but of your project. Here is worth the above point: test unitarily if you have something worth, and not only to achieve Coverage.

Browser other questions tagged php laravel tdd phpunit

You are not signed in. Login or sign up in order to post.