I guess we can add more tests while working on V2 JSON serializer. So I will keep this open some time.

If there are duplicates we could simply add comments in existing tests to describe additional scenarios are tested. If we can not create clear comments please keep duplicate tests.

@iSazonov Sorry for the initial submission with redundant tests. I've refactored based on your feedback:

Removed (covered by existing tests):

• null, arrays, hashtable (lines 94-107)
• Depth, AsArray, Multiple pipeline (lines 43-77)

Consolidated into TestCases format:

• Enum: default + -EnumsAsStrings
• EscapeHandling: EscapeHtml + EscapeNonAscii

Kept:

• Uri, Nested PSCustomObject (renamed), EscapeHandling default (renamed), Depth over 100 error

Added:

• Special floating-point values (Infinity, -Infinity, NaN)
• Empty array ($null)
• SwitchParameter ({"IsPresent":true/false})

Result: +29/-51 lines, removing redundancy while improving edge case coverage.

I'll add more test cases if I find other scenarios worth covering while working on V2 improvements.

@yotsuda Have we tests to cover all code paths for if (currentDepth > context.MaxDepth)? Notice, we don't add extended/adapted properties if isPurePSObj = true; and add otherwise.

@iSazonov Added tests covering both code paths for currentDepth > context.MaxDepth (b10f8be):

1. Pure PSObject (isPurePSObj = true): AddPsProperties returns early without adding ETS properties. The ToString() result is used as-is.
2. Non-pure PSObject (isPurePSObj = false): AddPsProperties processes ETS properties on the string-converted value.

# Pure PSObject - depth exceeded (isPurePSObj = true)
$pso = [PSCustomObject]@{ Name = 'test' }
$pso | Add-Member -NotePropertyName ETSProp -NotePropertyValue 'ets'
@{ inner = $pso } | ConvertTo-Json -Depth 0 -Compress
# Output: {"inner":"@{Name=test; ETSProp=ets}"}

# Non-pure PSObject (Version) - depth exceeded (isPurePSObj = false)
$version = [version]'1.2.3'
$version | Add-Member -NotePropertyName ETSProp -NotePropertyValue 'ets'
@{ inner = $version } | ConvertTo-Json -Depth 0 -Compress
# Output: {"inner":"1.2.3"}

Also added a comparison test for pure PSObject serialization within depth limit.

Also fixed the DateTime ETS test (f3025f7) to use UTC, avoiding timezone conversion issues that caused intermittent failures.

@yotsuda Thanks! I see if object is pure PSObject LanguagePrimitives.ConvertTo() does all work and add ETS properties so we skipp AddPSProperty(). But I wonder why these properties are not added if isPurePSObj == false - I'd expect AddPSProperty() should add. Thoughts?

@iSazonov Let me trace through the code flow (referring to V1/JsonObject.cs).

When isPurePSObj == false and currentDepth > MaxDepth:

1. The object is converted to string via LanguagePrimitives.ConvertTo(obj, typeof(string), ...) (line 618-619)
2. AddPsProperties is called with the converted string
3. Since isPurePSObj == false, we don't early-return at line 671-673
4. The string is wrapped in a new Dictionary with key "value" (line 680-682)
5. AppendPsProperties is called (line 685)

In AppendPsProperties:

• Line 710-712 checks if the original psObj.BaseObject is string or DateTime - if so, it returns early (no ETS properties added)
• Line 716-719: Since isCustomObj == false, only Extended properties are searched (not Adapted)
• Any Extended properties found are added to the dictionary

After AppendPsProperties returns:

• Line 687-690: If the original rv was not a dictionary and no properties were added (dict.Count == 1), the original string is returned instead of the dictionary wrapper

So the ETS properties are added for isPurePSObj == false when:

• The original BaseObject is not string/DateTime, AND
• Extended properties exist on the PSObject

The properties are not added when:

• BaseObject is string/DateTime (intentional, these types use their natural serialization)
• No Extended properties exist

Note for #26654 (V2/STJ): While testing this, I found an issue in WriteProperty where MaxDepth == 0 directly called ToString() without going through WriteDepthExceeded, so ETS properties on nested PSObjects were not included. I've fixed this in #26654 (commit 67a1bbd) and added a test to cover this case.

@yotsuda Please look failed tests.

I think it is time to switch to the PR and add more compatibility tests. I will share my thoughts as you will ready.

@iSazonov Fixed the cross-platform test failures by copying the test file from PR #26654 (feature-convertto-json-factory-v2).
The test file is now identical to the one in #26654.

@yotsuda It would be a pity to lose the experience that we gained while exploring the possibility of migrating to STJ.
If you have a desire to improve the ConvertTo-Json cmdlet, then you could start with tests.
I looked at what we have now. In fact, very little, poor test coverage.
Therefore, we could use the capabilities of AI and generate a complete set of tests so as to eliminate any regression with subsequent changes.
Below are my thoughts. Maybe I missed something.

Object types:

1. Primitive/scalar types + specific cases (string, datetime - ETS; BigInt; IPAddress?; URI?; NaN for double and so on)
2. Enum (+ enums as strings)
3. Arrays
4. Dictionary
5. PSCustomObject
6. Composite object (I'd prefer PowerShell class instead of FileInfo)

The following options are needed for each type of object:

1. Pipeline vs InputObject (e.g. PSObject wrapped vs unwrapped)
2. With ETS vs no ETS properties

Additionally, tests are needed for scenarios (most likely it is more convenient to combine them):

1. Depth truncation
2. Multilevel compositions

By Multilevel compositions, I mean that, for example, the elements of an array can be scalars, enums, array, dictionary, PSCustomObject and Composite object; the same applies to all other composite types.

Of course, for all combinations, this would be a huge set of tests. Therefore, they should be reduced reasonably. So we need to check all scalars, but for composite types it makes no sense to check all scalars - you can limit the list to string, datetime, int, enum plus nested composite types with the same restrictions.
Even in this case, it's likely that there will be too many tests for one PR.
It may be worth starting with scalars, as well as scalars as elements of other types.
Then array and dictionary. Then PSCustomObject and Composite object. Then Depth truncation and Multilevel compositions.

@iSazonov Thank you for sharing this comprehensive test plan! I completely agree that having thorough test coverage is essential before any changes to ConvertTo-Json.

Implementation

I've implemented Phase 1 (scalars + scalars as elements) in commit 735c6cf. The tests cover:

Total: 77 new tests

I plan to continue adding the remaining phases (Array, Dictionary, PSCustomObject, Composite, Depth truncation) in this same PR, unless you'd prefer separate PRs.

Interesting findings

While writing tests, I discovered some behaviors worth documenting:

• Guid via Pipeline includes Extended property, via InputObject serializes as string only
• TimeSpan serializes as object with all properties (not ISO string)
• double 0.0 serializes as "0.0" not "0"

All my PRs to this repo have been fully automated via PowerShell.MCP - investigating existing behavior, coding, building, and testing without writing a single line myself. Claude Code couldn't handle PowerShell this well.

The bigger picture: MCP connects AI to external tools, and countless purpose-specific MCP servers are being developed - Azure MCP Server, GitHub MCP Server, etc. PowerShell.MCP makes all of them obsolete - Az module is far more capable than Azure MCP Server, git.exe/gh.exe far more than GitHub MCP Server. AI can simply use these mature, full-featured tools directly through PowerShell. This positions PowerShell as the universal AI interface - I hope this could be good news for the PowerShell community. Feedback welcome!

cc: @mklement0

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Maintainer, please provide feedback and/or mark it as Waiting on Author