Add Test Coverage

[deniskorbakov]

Laravel has already developed very well and has become the best framework for PHP.

After looking at the repository with the framework itself, I did not find a test coverage check.

Perhaps it would be worth adding this check in order to improve the standard of code quality?

[KarkiGaurav]

Hi bro Laravel already has a large and well-maintained test suite, but you are right that there is no enforced coverage percentage in the CI pipeline. Adding an optional coverage check or publishing coverage reports could help contributors see gaps more clearly. However, enforcing a strict coverage threshold might slow down contributions, so maintainers usually avoid it.

[marius-ciclistu]

@deniskorbakov What gains do you see in 100% coverage? I see only negative ones.

[deniskorbakov]

@deniskorbakov What gains do you see in 100% coverage? I see only negative ones.

Okay, please give examples of Negative scenarios

[marius-ciclistu]

Chances are close to 100% that you need to change the unit tests when you make changes that DO NOT change the contract with your client.

Also you would need to change the code to make it testable via UNIT tests even if the code is respecting the contract and by doing so you risk introducing new issues.

Most important is that mocking the environment in which your unit of code runs will not help you discover corner cases from real situations, making it pretty much a waste of your time.

The tests that test the footprint generated by the code execution are the tests that mather and check that the contract is being respected.

Ex.
Any mark left by the code outsite the memory in which it runs. That can be DB, Cache, Files, Logs, Outside Buffer, Queue system, Outgoing calls ( http soap etc.), Responses (including streams) etc. The client who pays for the code looks at those not at the units of code.

Final notes.
If one doesn't trust its coding abilities, why should he trust his unit test coding abilities?

Code and test code that tests that initial code, should not be written by the same person.

If you want to make sure no one will change a piece of code because it might affect the contract, the (integration) test should cover that because there are multiple roads to the same destination.

Unit tests can almost double the cost at the initial moment and later when changes are needed, without making sure the contract is respected. Why pay for something if it does not help you as a client?

[deniskorbakov]

Thank you for the answer, but I do not agree with you, the percentage of test coverage will never be excessive, the product should always increase the quantity, quality and types of testing. Just to cover more and more borderline cases related to the code

[marius-ciclistu]

The good thing is that we are (still) free to have opinions and no one is forcing us to do as others say. Good luck and thank you too.

[ahinkle]

Tbh when you have a Taylor Otwell maintaining, you don't need test converge.

Also: I've had test coverage for years and found it to be a bit useless. e.g. phpstan catching things that test coverage often did not/false positives etc.

[deniskorbakov]

You are now talking about different concepts - a static analyzer and test coverage of possible branches in the program

It's like comparing an ass with a finger

[ahinkle]

uh no. enjoy yourself king.

[mbabker]

Tbh when you have a Taylor Otwell maintaining, you don't need test converge.

Uhh, yes, you do. Humans, no matter how long they have been writing code or what their own development practices are, are fallible. Then add in that code is being written by an untold number of would-be contributors, more frequently providing generated solutions (i.e. AI). Tests will verify behaviors that a human will not think about once those tests are written.

Also: I've had test coverage for years and found it to be a bit useless. e.g. phpstan catching things that test coverage often did not/false positives etc.

Static analysis versus runtime automated testing (unit/integration/feature tests) are two different, yet often complementary, concepts. There are things PHPStan will flag as warnings that a not-so-insignificant number of developers will ignore (i.e. there are a lot of code snippets out there that will ignore the potential false return from fopen()), that doesn't make the testing strategies bad. But, if you're comfortable using your production deployment and users as a quality assurance test team, more power to you.