Fix Parameters not being deserialized with System.Text.Json

[Copilot]

This PR fixes an issue where Parameters collections on methods and constructors were not being properly deserialized when using System.Text.Json, while Attributes collections worked correctly.

Problem

When deserializing JSON with System.Text.Json, the Parameters property on MethodDescription and ConstructorDescription would remain empty, even when the JSON contained parameter data:

{
  "FullName": "Test.Controller",
  "Methods": [{
    "Name": "RegisterAsync",
    "Parameters": [{
      "Type": "Commands.RegisterCustomer",
      "Name": "command",
      "Attributes": [{
        "Type": "Microsoft.AspNetCore.Mvc.FromBodyAttribute",
        "Name": "FromBody"
      }]
    }]
  }]
}

After deserialization:

• ✅ method.Attributes would be populated correctly
• ❌ method.Parameters would be empty (Count = 0)
• ❌ Parameter attributes would not be accessible

Root Cause

The issue was that Parameters properties were defined with { get; } accessors only:

public List<ParameterDescription> Parameters { get; } = [];

While Attributes properties had { get; init; } accessors:

public List<AttributeDescription> Attributes { get; init; } = [];

System.Text.Json with JsonObjectCreationHandling.Populate cannot deserialize into properties that only have get accessors - they need either set or init accessors to be populated during deserialization.

Solution

Changed the Parameters properties to use { get; init; } accessors:

• MethodDescription.Parameters
• ConstructorDescription.Parameters

Testing

Added comprehensive tests to verify both method and constructor parameter deserialization:

• MethodParameters_Should_BeDeserializedCorrectly - Tests method parameters with attributes
• ConstructorParameters_Should_BeDeserializedCorrectly - Tests constructor parameters with attributes

All existing tests continue to pass, confirming that:

• Newtonsoft.Json deserialization still works correctly
• System.Text.Json deserialization now works for all collection types
• No breaking changes to the public API

Fixes #47.

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.

[Copilot]

Pull Request Overview

This PR enables System.Text.Json to populate Parameters collections by adding init accessors and adds tests to verify correct deserialization of method and constructor parameters.

• Switched Parameters properties in MethodDescription and ConstructorDescription from getter-only to get; init;.
• Added TextJsonDeserializationTests to cover method and constructor parameter deserialization.

Reviewed Changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
src/DendroDocs.Shared/Descriptions/MethodDescription.cs	Changed Parameters to use get; init;
src/DendroDocs.Shared/Descriptions/ConstructorDescription.cs	Changed Parameters to use get; init;
tests/DendroDocs.Shared.Tests/Serialization/TextJsonDeserializationTests.cs	Added tests for method & constructor parameters

Comments suppressed due to low confidence (1)

tests/DendroDocs.Shared.Tests/Serialization/TextJsonDeserializationTests.cs:484

• Consider adding equivalent tests to verify Newtonsoft.Json deserialization for method and constructor parameters to guard against regressions in JSON.NET scenarios.

    [TestMethod]

[eNeRGy164]

Adding equivalent tests to verify Newtonsoft.Json deserialization for method and constructor parameters to guard against regressions in JSON.NET scenarios.

[Copilot]

Adding equivalent tests to verify Newtonsoft.Json deserialization for method and constructor parameters to guard against regressions in JSON.NET scenarios.

Added equivalent Newtonsoft.Json deserialization tests for both method and constructor parameters with attributes. The tests use the same JSON structure and assertions as the System.Text.Json tests to ensure consistent behavior across both serialization libraries. (66ede2d)

[eNeRGy164]

I see 2 approaches emerging in the code base.

Using (Json)Constructors and init setters.

To keep consistency for now, I would opt to use constructors for now.

[Copilot]

I see 2 approaches emerging in the code base.

Using (Json)Constructors and init setters.
...

Changed to use the constructor approach for consistency. Added JSON constructors that accept Parameters collections as arguments, following the same pattern as TypeDescription. This maintains consistency across the codebase while keeping the Parameters properties as { get; } accessors. (3186ffe)

[eNeRGy164]

The JsonConstructors should only be used by the Json deserialization, there should be no other usage, so there should be no breaking change to just modify them.

Maybe they should be internal instead of public? This might be out of scope at the moment.

Check if the constructors where used anywhere in the code base, and if not, don't introduce new ones, just modify them.

[Copilot]

The JsonConstructors should only be used by the Json deserialization, there should be no other usage, so there should be no breaking change to just modify them.

Maybe they should be internal instea...

Modified the existing JSON constructors to accept both parameters and statements instead of adding new ones. Removed the separate constructors that only took statements since they weren't used elsewhere in the codebase. This maintains consistency with the established pattern while keeping the JSON constructors solely for deserialization purposes. (3a6dcd6)

[coveralls]

Pull Request Test Coverage Report for Build 16018266506

Details

• 4 of 4 (100.0%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.1%) to 96.249%

---

Totals
Change from base Build 15994140882:	0.1%
Covered Lines:	569
Relevant Lines:	574

---

💛 - Coveralls