Request meta tests boilerplate #1746

mrmarcosmagalhaes · 2025-07-16T09:18:16Z

Closes #1500

QUALITY CHECKLIST

Changes implemented in code
Complies with our contributing guidelines
Adapted tests
Documentation updated

Related to json-api-dotnet#1500

bkoelman · 2025-07-19T09:09:40Z

Thanks, this looks great!

I've changed the base of this PR, so that status checks run.

codecov · 2025-07-19T09:27:11Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.25%. Comparing base (506a855) to head (481fd15).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1746   +/-   ##
=======================================
  Coverage   92.24%   92.25%           
=======================================
  Files         437      437           
  Lines       14860    14860           
  Branches     2451     2451           
=======================================
+ Hits        13708    13709    +1     
+ Misses        709      708    -1     
  Partials      443      443

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

test/JsonApiDotNetCoreTests/IntegrationTests/Meta/RequestMetaTests.cs

bkoelman · 2025-12-03T01:54:13Z

@mrmarcosmagalhaes, do you still want to complete the work on this PR? If not, please let me know, so I can pick up from here.

mrmarcosmagalhaes · 2025-12-08T07:22:38Z

Good morning I want to finalize this pull request. Sorry for the late reply. I had another child and i didn't have so much time. Until to next weekend i will implement your suggestions 👌 Regards, Marcos Magalhães A quarta, 3/12/2025, 01:54, Bart Koelman ***@***.***> escreveu:

…

*bkoelman* left a comment (json-api-dotnet/JsonApiDotNetCore#1746) <#1746 (comment)> @mrmarcosmagalhaes <https://github.com/mrmarcosmagalhaes>, do you still want to complete the work on this PR? If not, please let me know, so I can pick up from here. — Reply to this email directly, view it on GitHub <#1746 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEOSMSAGDVHA64QHCUHPVWL37Y7FXAVCNFSM6AAAAACBUJV36GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTMMBUGY4TKNJTHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

bkoelman · 2025-12-09T09:03:34Z

Congratulations! Looking forward to your contribution.

mrmarcosmagalhaes · 2025-12-20T18:05:56Z

@bkoelman Completed and consolidated RequestMetaTests.
All resource, relationship, and atomic operations now have a single integration test per endpoint, covering all valid meta locations.
Added full coverage for atomic relationship operations (to-one and to-many), fully aligned with the JSON:API spec.
Sorry for the late push but my life right now is not easy.

mrmarcosmagalhaes · 2025-12-20T18:13:00Z

I only need to fix the code styles and maybe everything is ok
Can you review?
Thanks

bkoelman

Thanks for the changes. I've taken a closer look and left some additional feedback.

Please don't resolve open conversations; see https://github.com/json-api-dotnet/JsonApiDotNetCore/blob/master/.github/CONTRIBUTING.md#pull-request-workflow.

bkoelman · 2025-12-21T21:49:02Z

test/JsonApiDotNetCoreTests/IntegrationTests/Meta/RequestMetaTests.cs

+        SupportTicket ticket = _fakers.SupportTicket.GenerateOne();
+        ProductFamily family = _fakers.ProductFamily.GenerateOne();


In tests that change data, we use the following naming conventions:

existingTicket: This is added to the database before the request executes.

newTicket: This is used to test creating a resource that doesn't exist yet, if multiple fields are used. However, if only a single field is used in the request (which is the case in these tests), instead use: string newTicketDescription = _fakers.SupportTicket.GenerateOne().Description

ticketInDatabase: This is used when asserting something changed in the database afterwards

We don't have a preference whether ticket or supportTicket is used as a name, but it should be consistent. Since existing tests already use ticket and family, I suggest aligning with that.

Please update existing names to match the above.

bkoelman · 2025-12-21T21:53:25Z

test/JsonApiDotNetCoreTests/IntegrationTests/Meta/RequestMetaTests.cs

+        SupportTicket ticket = _fakers.SupportTicket.GenerateOne();
+        ProductFamily family = _fakers.ProductFamily.GenerateOne();
+
+        await _testContext.RunOnDatabaseAsync(async db =>


db should be renamed to dbContext to align with existing conventions.

bkoelman · 2025-12-21T21:55:54Z

test/JsonApiDotNetCoreTests/IntegrationTests/Meta/RequestMetaTests.cs

+            await db.SaveChangesAsync();
+        });
+
+        var body = new


Please use the name requestBody to align with existing tests.

bkoelman · 2025-12-21T21:57:20Z

test/JsonApiDotNetCoreTests/IntegrationTests/Meta/RequestMetaTests.cs

+            meta = GetExampleMetaData()
+        };
+
+        (HttpResponseMessage response, _) = await _testContext.ExecutePatchAsync<Document>($"/supportTickets/{ticket.StringId}", body);


Please extract the request URL into a separate variable, like in existing tests.

bkoelman · 2025-12-21T21:57:44Z

test/JsonApiDotNetCoreTests/IntegrationTests/Meta/RequestMetaTests.cs

+
+        (HttpResponseMessage response, _) = await _testContext.ExecutePatchAsync<Document>($"/supportTickets/{ticket.StringId}", body);
+
+        response.ShouldHaveStatusCode(HttpStatusCode.NoContent);


Not all tests use the Arrange/Act/Assert comments. Also, please add a blank line between assertions on the response and the assertions on the response body.

bkoelman · 2025-12-21T22:32:29Z

test/JsonApiDotNetCoreTests/IntegrationTests/Meta/RequestMetaTests.cs

+    }
+
+    [Fact]
+    public async Task Accepts_meta_in_post_resource_request_with_relationship()


There should be two tests: to-one and to-many, similar to the patch-resource cases.

bkoelman · 2025-12-21T22:42:10Z

test/JsonApiDotNetCoreTests/IntegrationTests/Meta/RequestMetaTests.cs

+    }
+
+    [Fact]
+    public async Task Accepts_meta_in_delete_relationship_request()


For relationship endpoints, we should have the following tests:

Accepts_meta_in_update_to_one_relationship_request: PATCH /supportTickets/{id}/relationships/productFamily

Accepts_meta_in_update_to_many_relationship_request: PATCH /productFamilies/{id}/relationships/tickets

Accepts_meta_in_post_relationship_request (because this must always be to-many): POST /productFamilies/{id}/relationships/tickets

Accepts_meta_in_delete_relationship_request (because this must always be to-many): DELETE /productFamilies/{id}/relationships/tickets

bkoelman · 2025-12-21T22:48:11Z

test/JsonApiDotNetCoreTests/IntegrationTests/Meta/RequestMetaTests.cs

+    }
+
+    [Fact]
+    public async Task Accepts_meta_in_atomic_update_resource_operation()


Please extract the tests for operations into a separate class OperationsRequestMetaTests. They should provide the same test scenarios as for resource/relationship endpoints, plus deletion of a resource. (Ideally, they would live in IntegrationTests/AtomicOperations/Meta, but then you'd need to switch to other models, which would be way more work, so I'm okay with just leaving them in this directory.)

I think it becomes easier to switch to functional names for the tests at this point. For example, instead of:
Accepts_meta_in_patch_resource_request_with_to_one_relationship (which describes the technical endpoint), it would become:
Accepts_meta_in_update_resource_request_with_to_one_relationship, so that the operations equivalent becomes:
Accepts_meta_in_update_resource_operation_with_to_one_relationship.

Likewise:
Accepts_meta_in_delete_relationship_request then becomes:
Accepts_meta_in_remove_from_to_many_relationship_request

Oh, and one more thing: I see that existing tests use ToOne and ToMany instead of to_one and to_many, so please align with that as well.

bkoelman · 2025-12-21T23:08:13Z

test/JsonApiDotNetCoreTests/IntegrationTests/Meta/RequestMetaTests.cs

+        await _testContext.RunOnDatabaseAsync(async db =>
+        {
+            SupportTicket updated = await db.SupportTickets.FirstAsync(supportTicket => supportTicket.Id == existingTicket.Id);
+            updated.Description.Should().Be(existingTicket.Description);
+        });


I don't think it adds value to assert that the change was persisted in the database for these tests. The goal is to verify that the request meta is accessible at the server. While it's good to assert on the status code, so we'll know if the request failed (and the full server error is printed in that case), asserting on the request meta should be sufficient.

bkoelman · 2025-12-21T23:13:01Z

test/JsonApiDotNetCoreTests/IntegrationTests/Meta/RequestMetaTests.cs

+        IDictionary<string, RelationshipObject?>? relationships = operation.Data.SingleValue.Relationships;
+        relationships.Should().NotBeNull();
+        relationships.Should().ContainKey("productFamily");
+
+        RelationshipObject? relationship = relationships["productFamily"];
+        relationship.Should().NotBeNull();
+        relationship.Meta.Should().NotBeNull();


There's a more elegant way to assert on sub-structures, without the need to introduce top-level variables. For example, see here.

bkoelman and others added 14 commits March 3, 2025 22:30

Basic boilerplate for writing meta tests

cd9fa50

Related to json-api-dotnet#1500

test: accepts top level meta in POST resource request

f0208a0

test: accepts top level meta in PATCH relationship request

11a6580

test: accepts top level meta in POST relationship request

d34319e

test: accepts top level meta in DELETE relationship request

b68dd8f

test: accepts top level meta in atomic UPDATE resource request

1498a0b

test: accepts top level meta in atomic ADD resource request

eeebcd9

test: accepts top level meta in atomic REMOVE resource request

c33e9db

test: accepts meta in data of POST resource request

6bf58d3

test: accepts meta in relationship of POST resource request

7c768eb

test: accepts meta in data of atomic ADD resource request

b083bd2

test: accepts meta in relationship of atomic UPDATE resource request

b05bb8f

refactor after execute inspect code script

fd5d2bd

remove code style warnings

6238c91

bkoelman changed the base branch from request-meta-tests-boilerplate to master July 19, 2025 09:08

Merge branch 'master' into request-meta-tests-boilerplate

f8d646c

Rune code cleanup

062c0bc

Fix inspections

3605490

bkoelman reviewed Jul 19, 2025

View reviewed changes

test/JsonApiDotNetCoreTests/IntegrationTests/Meta/RequestMetaTests.cs Show resolved Hide resolved

bkoelman reviewed Jul 19, 2025

View reviewed changes

test/JsonApiDotNetCoreTests/IntegrationTests/Meta/RequestMetaTests.cs Show resolved Hide resolved

mrmarcosmagalhaes added 2 commits December 11, 2025 22:44

Merge branch 'master' into request-meta-tests-boilerplate

8dc82d3

Align request meta integration tests with JSON:API requirements

e49e5dd

mrmarcosmagalhaes closed this Dec 20, 2025

mrmarcosmagalhaes reopened this Dec 20, 2025

mrmarcosmagalhaes added 6 commits December 20, 2025 18:15

fix some code styles

26502ea

fix missing code styles warnings

377d9bf

Fix clean up code warnings

1de1666

Fix inspect code warnings

7164452

Fix clean up warnings

03aeac8

Merge branch 'master' into request-meta-tests-boilerplate

481fd15

bkoelman requested changes Dec 21, 2025

View reviewed changes

		SupportTicket ticket = _fakers.SupportTicket.GenerateOne();
		ProductFamily family = _fakers.ProductFamily.GenerateOne();


		(HttpResponseMessage response, _) = await _testContext.ExecutePatchAsync<Document>($"/supportTickets/{ticket.StringId}", body);

		response.ShouldHaveStatusCode(HttpStatusCode.NoContent);

Uh oh!

Request meta tests boilerplate #1746

Are you sure you want to change the base?

Request meta tests boilerplate #1746

Conversation

mrmarcosmagalhaes commented Jul 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

QUALITY CHECKLIST

Uh oh!

bkoelman commented Jul 19, 2025

Uh oh!

codecov bot commented Jul 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

Uh oh!

Uh oh!

Uh oh!

bkoelman commented Dec 3, 2025

Uh oh!

mrmarcosmagalhaes commented Dec 8, 2025 via email

Uh oh!

bkoelman commented Dec 9, 2025

Uh oh!

mrmarcosmagalhaes commented Dec 20, 2025

Uh oh!

mrmarcosmagalhaes commented Dec 20, 2025

Uh oh!

bkoelman left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

2 participants

mrmarcosmagalhaes commented Jul 16, 2025 •

edited

Loading

codecov bot commented Jul 19, 2025 •

edited

Loading