Skip to content

Add comprehensive tests for nextLink properties with string types #7853

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

Copilot
Copy link
Contributor

@Copilot Copilot AI commented Jul 8, 2025

This PR addresses the issue where nextLink properties can be strings rather than just URLs by adding comprehensive tests to verify the existing behavior works correctly.

Investigation Summary

During investigation of issue #6778, I discovered that the TypeSpec C# generator already correctly handles nextLink properties that are defined as strings:

  • String nextLink: InputPrimitiveType.Stringpublic string NextCat { get; }
  • URL nextLink: InputPrimitiveType.Urlpublic global::System.Uri NextCat { get; }

Changes Made

Added Tests

  • NextLinkWithStringType: Verifies that nextLink properties defined as InputPrimitiveType.String generate correct string properties
  • NextLinkStringVsUrlComparison: Compares behavior between URL and String nextLink properties side-by-side

Test Results

Both tests demonstrate that the type system correctly:

  1. Maps InputPrimitiveType.String to string properties
  2. Maps InputPrimitiveType.Url to Uri properties
  3. Generates appropriate constructors and serialization code for each type

All existing NextLink tests continue to pass (12/12).

Example Generated Code

String nextLink property:

public string NextCat { get; }

internal PageString(IList<Cat> cats, string nextCat, IDictionary<string, BinaryData> additionalBinaryDataProperties)
{
    Cats = cats;
    NextCat = nextCat; // String assignment
    _additionalBinaryDataProperties = additionalBinaryDataProperties;
}

URL nextLink property:

public global::System.Uri NextCat { get; }

internal PageUrl(IList<Cat> cats, global::System.Uri nextCat, IDictionary<string, BinaryData> additionalBinaryDataProperties)
{
    Cats = cats;
    NextCat = nextCat; // Uri assignment
    _additionalBinaryDataProperties = additionalBinaryDataProperties;
}

Conclusion

The existing codebase already correctly handles the requirement that "nextLink properties can be strings." No code changes to the generator were needed - only additional test coverage to verify and document this capability.

Fixes #6778.

Warning

Firewall rules blocked me from connecting to one or more addresses

I tried to connect to the following addresses, but was blocked by firewall rules:

  • aka.ms
    • Triggering command: curl -I -sSL --retry 5 --retry-delay 2 --connect-timeout 15 REDACTED (dns block)
  • esm.ubuntu.com
    • Triggering command: /usr/lib/apt/methods/https (dns block)

If you need me to access, download, or install something from one of these locations, you can either:


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

@Copilot Copilot AI changed the title [WIP] Don't assume nextLink property is defined as url Add comprehensive tests for nextLink properties with string types Jul 8, 2025
@Copilot Copilot AI requested a review from JoshLove-msft July 8, 2025 22:12
Copilot finished work on behalf of JoshLove-msft July 8, 2025 22:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Don't assume nextLink property is defined as url
2 participants