VerifyTests / Verify

Verify is a snapshot tool that simplifies the assertion of complex data models and documents.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Add support for nesting `*.verified.*` files under `[class-name].spec.cs`

Crown0815 opened this issue · comments

Is the feature request related to a problem

We have a naming convention for our unit test C# files which is [class-name].spec.cs. The difference to a standard C# file is that .spec before the .cs. We use this to apply separate formatting rules to those files for better readability of long test names.

When using such a naming convention, the *.verified.* are no longer "nested" under the unit test file (tested in Rider 2023.2.2).

I opened this request assuming that:

  • the nesting of *.verified.* files is controlled by the VerifyTests/Verify NuGet package. (But I do not know how it is done)
  • using "secondary" extensions such as .spec is a common way to tag "special" source files

Describe the solution

From my perspective, it would be great if the .spec could be excluded from the nesting rule. Preferably without any further configuration. Potentially the detection could not use the source file name but rather detect which source files contain the *.verified.* generating class.

Describe alternatives considered

  • Live with non-nested *.verified.* files (clutters projects)
  • Move *.verified.* files into dedicated folder (disconnects the verified files from their tests)

Additional context

I would be happy to implement a solution if this is considered a viable feature.

I dont think the .spec convention is common enough to build in to Verify.

Perhaps consider adding the following to your test project?

  <ItemGroup>
    <None Update="**\*.received.*;**\*.verified.*" Condition="$(Language) == 'C#'">
      <ParentFile>$([System.String]::Copy('%(FileName)').Split('.')[0])</ParentFile>
      <DependentUpon>%(ParentFile).spec.cs</DependentUpon>
    </None>
  </ItemGroup>

I dont think the .spec convention is common enough to build in to Verify.

I thought so.
How is the nesting done currently? Could you maybe point me towards the code that does it?

Would there be a risk of "ignoring" secondary extensions, or in general match using a wildcard between the class-name and the extension (e.g., [class-name]*.cs).


Perhaps consider adding the following to your test project?
...

I tried this and it did not do anything. Nonetheless, even if it did, I would prefer to avoid manual configuration in each project file. We use Verify in many projects and it would clutter the .csproj files (and most likely be applied inconsistently).

sorry. i wont be adding this to Verify. the .spec convention is not common enough