Unit testing of an app with shared db

@yeasir_arafat Why do you have a Laravel app that speaks to a Laravel app? Your users now how to wait for two sequential network calls to complete instead of just one. You’ve literally doubled your response times.

I would suggest making a whole new project and not use the two like that. If it's an existing working app why does it need test?

Tests are only as good as the developer who wrote them. Having said that, any experienced developer would agree that TDD and test coverage is imperative. I would never dream of running anything in production without test coverage.

@yeasir_arafat Yes, I actually do have this similar architecture for an application. I have a main API that is consumed by a few applications. Two of those applications are in-house (or intranet only) used by internal employees. The other app is a customer portal that is publicly accessible. The reason why it has its own Laravel app is for the sake of security. We're talking about an application that is responsible for managing projects worth multi-millions of dollars. We can configure our main API (and firewall) to only accept incoming requests from that public facing server, which basically serves as a proxy or service layer. The database and domain logic is all on our main API, buried behind a firewall. If the public API was ever compromised, there would be no data breach (or minimal) and very little code. This allows us to be very selective in what we expose to the internet.

Again, having all our data and logic in the main API, we really don't need to worry about shared unit testing. The portal API is basically just a delegating relay service. For form validation, I wrote some middleware for Laravel's HTTP client, which intercepts 422 responses, and basically hydrates a validator with all the errors and automatically bubbles it up to the client. It works very smoothly for passing errors directly through the service.

After saying all this, in our case, there is a small need to unit test across multiple databases, such as the user models for external clients/customers. What you were thinking is along the same lines as what we have done. Even though the external users are within another database/app, I created a migration for them that is only ran if the environment is for testing:

public function up()
    {
        if (\App::environment('testing'))
        {

            Schema::connection(config('database.portal'))->create('users', function (Blueprint $table) {
                $table->id();
                $table->string('name');
                $table->string('email');
                $table->string('password');
                $table->timestamps();
            });
        }
    }

As you can see, it only runs if the environment is testing, which would be when phpunit is executed. This will create the migration for testing, but keep it out of any other environment deployment. You can also see on the Schema facade I make a call to connection(), which uses another database connection/configuration so I don't have a collision with the same users table name. This connection would also be set to localhost to simulate the external database for the tests. So the actual migration of the external users table is controlled by the portal application, but here we've faked it for testing. You'd also want to create an entry in phpunit.xml for the database connection. I use an in memory database, so something like:

 <env name="PORTAL_DB_CONNECTION" value="portal_memory_testing"/>
 <env name="PORTAL_DB_DATABASE" value=":memory:"/>

And then add the database configuration to your config/database.php

I then created an abstract model class to use for any of the external models where they override the constructor and set the database connection:

abstract class PortalModel extends Model
{

    public function __construct(array $attributes = [])
    {
    
        parent::__construct($attributes);

        $this->setConnection(config('database.portal'));
    
    }
}

Now this allows me create model classes such as:

class ClientUser extends PortalModel implements ApplicationUser
{

    use HasFactory;

    public function projects()
    {

        $this->connection = env('DB_CONNECTION');

        return $this->belongsToMany(Project::class, 'project_user');
    
    }

And create factories:

class ClientUserFactory extends Factory
{

    protected $model = ClientUser::class;

    protected $connection = 'portal';

    /**
     * Define the model's default state.
     *
     * @return array
     */
    public function definition()
    {
        
        return [
            'name' => $this->faker->name(),
            'email' => $this->faker->unique()->safeEmail(),
            'password' => $this->faker->lexify('?????????'),
        ];
    }

and perform tests:

class ClientUserTest extends TestCase
{

    /** @test */
    public function it_can_belong_to_many_projects()
    {

        $user = ClientUser::factory()->has(Project::factory()->count(3))->create();

        $this->assertEquals(3, $user->projects->count());

    }

This might seem convoluted at first, but once its set up, you don't have to think about it any longer. This app has over 2000 tests and growing, and I haven't given this a second thought in over a year.

Hopefully this helps you.

@yeasir_arafat

Any suggestion/experience regarding how that can be achieved without duplicating the foreign model, factory, migration etc?

I don't think there is any way around it, you'd need to create them. In my case, it's mostly just the users table. Our internal applications authenticate against Azure AD, where the client portal uses Laravel's authentication (Fortify/Sanctum), which is yet another reason for having a separate API. It sounds like the main difference is that your YY app has more responsibility and can manipulate the database directly. In my case, the portal app only interacts with data from its own database, and that's strictly just for the users/password resets/personal access token tables. Everything else gets delegated through the main API to handle.

Where it becomes interesting is the user relationships. For example, an internal user (employee) can have many Projects, but also so can an external (customer) user. In those cases, I ended up creating user_id and client_user_id fields for the foreign keys. The application knows which database to use because of the model connection that I shared above. It knows which field to use for the foreign key because laravel conventions, for this specific case, it knows to use the cleint_user_id column. Fortunately, the external portal app only uses a fraction of the application's features, so this solution doesn't pollute many tables.

There's no argument it's a pain initially. As you said, there may be other/better ways, but I found this to work for our case, and once established, it's been solid ever since. What I have found is that when you create the migrations/factories/models, you can get away with just the minimum. I just needed to basically define the ids to be able to create the relationship tests. The main API doesn't care about the email verification fields, etc, and it never will.. so I didn't bother including any of that. I kept things as light as possible just to get the tests working.