Reintegrate Community-Driven Test Suites

[RDPerera]

Purpose

This PR aims to reintroduce community-driven test suites into the ballerina/toml. These test suites were previously managed as Git submodules and are critical for ensuring the robustness and reliability of the read APIs provided by these modules.

Related to: ballerina-platform/ballerina-library#6129

Examples

N/A - This PR focuses on test suite integration rather than API usage examples.

Checklist

• Linked to an issue (#6129)
• Updated the changelog
• Added tests
• Updated the spec (if applicable)
• Checked native-image compatibility (if applicable)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.64%. Comparing base (7fd3f84) to head (62e28a4).

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #38      +/-   ##
==========================================
+ Coverage   95.53%   98.64%   +3.10%     
==========================================
  Files          23       23              
  Lines        1031     1031              
  Branches      672      672              
==========================================
+ Hits          985     1017      +32     
+ Misses         46       14      -32     

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

[nipunayf]

Let's not close the issue with this PR. Better if we can use Related to instead of Fixes since we need to add the fix for the YAML module as well.

[nipunayf]

The current flow only keeps the resource files during the Gradle build. This is fine in a workflow build; however, as a developer, it's better if we can have the test resources cloned at all times. So, can we include the .gitmodules as well, so the developer can clone the modules recursively at the beginning. WDYT?

[RDPerera]

Changed with 9bda069.

[nipunayf]

LGTM

[NipunaRanasinghe]

Any reason to use the fork instead of the original repo (https://github.com/toml-lang/toml-test) for the submodule? @nipunayf any idea?

[nipunayf]

Ultimately, this decision is made to have control over the test suite. If there are new test cases that have breaking changes to the supported specification, then the lang library would fail. Ideally, in such cases, we should handle it in a different major version rather than allowing the build to fail. More importantly, some cases were modified or removed intentionally due to a few limitations in the Ballerina language, since the modules were designed to be pure Ballerina.

[NipunaRanasinghe]

Ack. That makes sense.