Looking for documentation/examples of unit testing/integration testing of the GraphQL library with laravel

[drewg2009]

Are there any examples of unit testing/integration testing for the rebing graphql-laravel library?

I haven't seen any yet and my team wants to make sure our code is covered.

Thanks!

[mfn]

Not sure I understand correctly… it's a Laravel library, so once you install/enable it and make a simply test to verify it's working, you can use your favorite built-in Laravel test method.

That would be https://laravel.com/docs/9.x/http-tests#testing-json-apis or, if you need to go lower, you can use \Illuminate\Foundation\Testing\Concerns\MakesHttpRequests::call directly (I use the latter exclusive.

Is this what you meant?

[drewg2009]

How do I test the GraphQL queries and mutations with mocking objects and asserting results?

…

On Sat, Sep 17, 2022 at 4:42 PM Markus Podar ***@***.***> wrote: Not sure I understand correctly… it's a Laravel library, so once you install/enable it and make a simply test to verify it's working, you can use your favorite built-in Laravel test method. That would be https://laravel.com/docs/9.x/http-tests#testing-json-apis or, if you need to go lower, you can use \Illuminate\Foundation\Testing\Concerns\MakesHttpRequests::call directly (I use the latter exclusive. Is this what you meant? — Reply to this email directly, view it on GitHub <#940 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC7U7TXT3A3BJIQMZSDKYBLV6YNLLANCNFSM6AAAAAAQNVJCIY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[mfn]

• you can use the Laravel http testing features: it's just HTTP, usually a POST request, with the payload correctly formatted. You'll likely want to come up with a helper for that, otherwise there's not more to it
• if you're using SelectFields I'm not sure there's much mocking you can do: it directly works with Eloquent so it's more a feature/integration test
• otherwise, you can use DI in your query resolvers and inject the repositories and that's where you can start to mock things

[drewg2009]

Ok, but I want to use PHPUnit and do unit testing. I want to call the resolve method and mock other dependencies. I was hoping documentation could be added to show how its done in practice

…

On Sat, Sep 17, 2022 at 4:47 PM Markus Podar ***@***.***> wrote: - you can use the Laravel http testing features: it's just HTTP, usually a POST request, with the payload correctly formatted. You'll likely want to come up with a helper for that, otherwise there's not more to it - if you're using SelectFields I'm not sure there's much mocking you can do: it directly works with Eloquent so it's more a feature/integration test - otherwise, you can use DI in your query resolvers and inject the repositories and that's where you can start to mock things — Reply to this email directly, view it on GitHub <#940 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC7U7TXOH7YLJX5ER63VNLLV6YN6RANCNFSM6AAAAAAQNVJCIY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[mfn]

I don't know how feasible it is to pure unit test a type/query by itself; I think it depends on your use of the context, ResolveInfo and maybe other stuff. I never tried it that way, because I want to test:

• the graphql type system works as expected, i.e. reacts correct to the correct/wrong types I pass, including the validation from graphql-laravel when I use it
• otherwise I test the repositories by itself I call from various resolvers
• and then you only covered the return of the resolve in query, but have not resolved any other types
• special field resolvers are usually just closures, so it will be harder to just test them

IDK, going in with a pure unit test approach for something which is an integration of two complex frameworks (GraphQL, Laravel) might cause quite a lot of friction. I'd probably just try to separate it at the junction I mentioned beforehand.

---

Going technical, for a pure unit test, just instantiate the query and the call it's ->resolve() methods and you'll see how your results are. Mock the context and ResolveInfo for a start.

You'll however learn that you're now responsible for passing a proper $args into it; something the GraphQL type system takes care of for you. Also you won't have the validation protections this way. YMMV.

[drewg2009]

The goal with unit testing is more so to test the business logic in the resolver that is called.

We could just test those classes on their own, independently of the resolver to ensure it works.

However, testing with the resolver ensures it works when put together.

[mfn]

That's what I'm doing, both actually

• always having the business logic in independent classes (they know nothing about GraphQL)
• write feature test utilizing Laravels ->call() from the http trait and

Usually the feature tests for the GraphQL part are basic to ensure "it's working", and the coverage of the repositories is full on.

[jacksontong]

This is what I do for unit testing

<?php

use App\Models\Proposal;
use function Pest\Laravel\post;

it('fetches proposal', function () {
    $user = Sanctum::actingAs(
        User::factory()->create()
    );
    $proposal = Proposal::factory()
        ->for($user)
        ->create();

    post(route('graphql'), [
        'query' => <<<GQL
{
    proposal(id: $proposal->id) {
        id
        title
    }
}
GQL
    ])
        ->assertJson([
            'data' => [
                'proposal' => [
                    'id' => $proposal->id,
                ]
            ]
        ])
        ->assertJsonMissingPath('data.proposal.createdAt');
});