Laravel - Match test directory to app directory - laravel

Question

I have a pretty big Laravel 5.6 application I'm currently developing. By default, Larvel comes with a tests directory along with a tests/Unit and tests/Feature sub directories.
When I first started developing my app, any test I wrote that didn't require a full HTTP life cycle to take place, I would put in the tests/Unit directory.
Example: Testing a custom local query scope on a model.
Similarly, any test that did require a full HTTP life cycle I would put in the tests/Feature directory.
Example: Testing controllers using a GET, POST, etc request and making sure I got back a 200 response or equivalent.
Now that my application has grown to be quite massive, I'm starting to think that there should be a better way to organize my tests directory. I'm also noticing that parts of my code base do not have test coverage based on reports from codecov.io.
In my mind, it would make sense to create a tests/App directory and have that mirror all my files and classes in the app directory of the project root. Each class and/or file would have a corresponding test. This way, I'll have a better idea of which parts of my app have test coverage and which ones do not. I haven't seen any other projects that do this so I'm hesitant to apply this approach.
So, to summarize my question:
Are there any pitfalls with structuring the tests directory exactly like the app directory?
Is there an alternative way to structure your test directory so that you can tell with ease which classes/files have corresponding tests?
Side Note: I'm well aware that my unit tests don't adhere to the "normal" convention of mocking out your dependencies and testing in isolation. This is a separate issue but in short I feel that mocking doesn't allow you to refactor you code with ease. More info on what I'm talking about in my defense: https://www.youtube.com/watch?v=LdUKfbG713M

Answer 1

I'm also using the structure that Laravel provided. but I have made little changes. for example for functional testing, I have added an admin folder so I can write tests for admin APIs or for unit testing I have added (unit/cron, unit/middleware, unit/jobs, ...) this way I can control the directories.
tests/functional/admin
tests/unit/cron
tests/unit/middleware
tests/unit/jobs
tests/unit/policy
tests/unit/models
...
And also to see which API or function has a test or not it's a little hard to have it. If you are following the TDD principle then no need to worry about this part because you know that everyone who writes a piece of code he/she will write the test for it. but if you are not following the TDD and you have just started with writing tests for your project then you need to run PHPUnit coverage with --HTML tag and it'll return for you the HTML graph which can tell you how much code coverage your project has.

Answer 2

All Laravel projects start from an initial template,
if you check the phpunit.xml which the template normally includes, you should find:
...
<testsuites>
<testsuite name="Unit">
<directory suffix="Test.php">./tests/Unit</directory>
</testsuite>
<testsuite name="Feature">
<directory suffix="Test.php">./tests/Feature</directory>
</testsuite>
</testsuites>
All this does is tell PHPUnit to execute/run Unit folder's tests before Feature folder's tests.
The reason for that being;
If a normally small Unit is failing any test,
Then it makes no sense to search for the bug in normally large Feature(s),
And PHPUnit's report shows Unit folder's test-results at top,
which suggests that those should be fixed first, because debugging an entire Feature is normally harder than debugging a small Unit.
Example
Knowing above should help you decide for yourself;
But if you ask me, I would simply create an App folder in Unit folder, or add an additional testsuite to phpunit.xml file, right after Unit entry, like:
<?xml version="1.0" encoding="UTF-8"?>
<phpunit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="./vendor/phpunit/phpunit/phpunit.xsd"
backupGlobals="false"
backupStaticAttributes="false"
bootstrap="vendor/autoload.php"
colors="true"
convertErrorsToExceptions="true"
convertNoticesToExceptions="true"
convertWarningsToExceptions="true"
processIsolation="false"
stopOnFailure="false"
>
<testsuites>
<testsuite name="Unit">
<directory suffix="Test.php">./tests/Unit</directory>
</testsuite>
<testsuite name="Feature">
<directory suffix="Test.php">./tests/Feature</directory>
</testsuite>
<testsuite name="App">
<directory suffix="Test.php">./tests/App</directory>
</testsuite>
</testsuites>
<filter>
<whitelist processUncoveredFilesFromWhitelist="true">
<directory suffix=".php">./app</directory>
</whitelist>
</filter>
<php>
<server name="APP_ENV" value="testing"/>
<server name="BCRYPT_ROUNDS" value="4"/>
<server name="CACHE_DRIVER" value="array"/>
<!-- <server name="DB_CONNECTION" value="sqlite"/> -->
<!-- <server name="DB_DATABASE" value=":memory:"/> -->
<server name="MAIL_MAILER" value="array"/>
<server name="QUEUE_CONNECTION" value="sync"/>
<server name="SESSION_DRIVER" value="array"/>
<server name="TELESCOPE_ENABLED" value="false"/>
</php>
</phpunit>
Because having one test-file beside each php-file is a Unit-testing style, not Feature-testing, even if the test requires "full HTTP life cycle".