VerifyTests / Verify
Verify is a snapshot testing tool that simplifies the assertion of complex data models and documents.
AI Architecture Analysis
This repository is indexed by RepoMind. By analyzing VerifyTests/Verify in our AI interface, you can instantly generate complete architecture diagrams, visualize control flows, and perform automated security audits across the entire codebase.
Our Agentic Context Augmented Generation (Agentic CAG) engine loads full source files into context on-demand, avoiding the fragmentation of traditional RAG systems. Ask questions about the architecture, dependencies, or specific features to see it in action.
Repository Overview (README excerpt)
Crawler viewVerify Verify is a snapshot tool that simplifies the assertion of complex data models and documents. Verify is called on the test result during the assertion phase. It serializes that result and stores it in a file that matches the test name. On the next test execution, the result is again serialized and compared to the existing file. The test will fail if the two snapshots do not match: either the change is unexpected, or the reference snapshot needs to be updated to the new result. **See Milestones for release notes.** Sponsors Entity Framework Extensions Entity Framework Extensions is a major sponsor and is proud to contribute to the development this project. Developed using JetBrains IDEs TestMu AI Browser testing via Requirements • Supported runtimes: net462, net472, net48, net481, net6, net8, net9, and net10. • Supported SDK: 9.0.301 and up Getting started wizard Get customized instructions for the specific combination of Operating System, IDE, Test Framework, and Build Server. Start wizard. NuGet • https://nuget.org/packages/Verify.NUnit/ • https://nuget.org/packages/Verify.XunitV3/ • https://nuget.org/packages/Verify.Fixie/ • https://nuget.org/packages/Verify.Expecto/ • https://nuget.org/packages/Verify.MSTest/ • https://nuget.org/packages/Verify.TUnit/ Snapshot management Accepting or declining a snapshot file is part of the core workflow of Verify. There are several ways to do this and the approach(s) selected is a personal preference. • In the Windows Tray via DiffEngineTray • ReSharper test runner plugin (Source) • Rider test runner plugin (Source) • Via the clipboard. • Manually making the change in the launched diff tool. Either with a copy paste, or some tools have commands to automate this via a shortcut or a button. • Manually on the file system, by renaming the file to . This can be automated via scripts to bulk accept all files by matching a pattern. • Using the dotnet tool Verify.Terminal. Usage ImplicitUsings **All examples use Implicit Usings. Ensure is set to to ensure examples compile correctly.** If are not enabled, substitute usages of with . Class being tested Given a class to be tested: snippet source | anchor NUnit Support for NUnit snippet source | anchor xUnitV3 Support for xUnitV3 snippet source | anchor Fixie Support for Fixie snippet source | anchor Fixie is less opinionated than other test frameworks. As such it leaves up to the consumer how to configure test execution. To enable Verify the ITestProject and IExecution interfaces need to be used. Requirements: • Assign the target assembly in using • Wrap test executions in using An example implementation of the above: snippet source | anchor Expecto Support for Expecto snippet source | anchor Caveats Due to the nature of the Expecto implementation, the following APIs in Verify are not supported. • • TUnit Support for TUnit snippet source | anchor MSTest Support for MSTest snippet source | anchor Marking tests as 'Using Verify' The MSTest implementation leverages a Source Generator and requires test classes to opt in to being processed by the Source Generator. Add the . For all test classes in an assembly: For a specific a test class: Or inherit from : snippet source | anchor Initial Verification No existing file. When the test is initially run it will fail. If a Diff Tool is detected it will be used to display the diff. To verify the result: • Execute the command from the Clipboard, or • Accept with DiffEngineTray tool, • Accept with ReSharper Plugin or Rider Plugin • Use the diff tool to accept the changes, or • Manually copy the text to the new file Verified result This will result in the being created: snippet source | anchor Subsequent Verification Existing file. If the implementation of changes: snippet source | anchor And the test is re-run it will fail. The Diff Tool will display the diff: The same approach can be used to verify the results and the change to is committed to source control along with the change to . Async has overloads that accept , , and . These are ed before verification. There is also an overload that accepts , which works well with lambda expressions: snippet source | anchor VerifyJson performs the following actions • Convert to (if necessary). • Apply ignore member by name for keys. • PrettyPrint the resulting text. snippet source | anchor Results in a .txt file: snippet source | anchor Conventions Source control Includes/Excludes • **All files should be excluded from source control.** eg. add the following to If using UseSplitModeForUniqueDirectory also include: All files should be committed to source control. Text file settings Text variants of verified and received have the following characteristics: • UTF8 with a Byte order mark (BOM) • Newlines as line-feed (lf) • No trailing newline This manifests in several ways: Source control settings All text extensions of should have: • set to • set to Note: is correct even though Verify writes files with a BOM. Git does not strip or add the BOM — it passes through transparently. The encoding would explicitly add a BOM on checkout and strip it on commit (so the internal blob differs from the working tree), but that is not the desired behavior since Verify writes the BOM itself and it should be preserved in the blob. All Binary files should also be marked to avoid merging and line ending issues with binary files. eg add the following _...truncated for preview_