Verify VS Bogus

Bogus - For creating fake data Verify - Snapshot testing for .NET MELT - For testing ILogger usage Stryker - Mutation Testing for .NET TestContainers - run docker programmatically in integration tests

Are you familiar with "snapshot testing" tools such as Verify that store expected output in files. It's still unit testing.

We can use Verify to perform snapshot testing and check for the correct output of the program. In order to make things easier and simplify working with process output capturing and invocation, I used CliWrap.

You will have to write extra code to set up a code base to get it started (there's always a large initial cost in getting things set up, and you'll be writing code that helps get the state of your application setup), but I can assure you that our team paid the initial tax and the only reason our tests change now is because of requirements changes (and maybe sometimes because the testing tools we use like Verify have some breaking changes in behavior when we upgrade). Otherwise, it helps us identify issues in our code, particularly when we do library upgrades or change to a different library. Again, our tests do not change when we completely reimplement anything, just when the external contract changes. We just get to refactor/reimplement and have confidence that the old behavior stays the same. And then you get to hook up a benchmark to your tests and, if your reason for refactoring was performance reasons, you can show that it was effective.

I assume this means you can take something like this, combine it with Snapshot/Approval testing (link to a library I have used), and then you have some quick-to-generate tests that help guard against regressions (even visual ones) by say:

Bogus NuGet package is fake data generator which can be helpful for populating tables in a database and testing purposes. If a database is not used and Bogus populates list of data each time an application runs, the data is random, never the same. Also, the random data generated by Bogus may not meet a developer’s requirements.

A list is populated with NuGet package Bogus.

Other project either mocked data using NuGet package Bogus or a json file.

That reminds me of Bogus which also generates dummy data that I've been using for sometime now.

To do all this you need test though...and that's where ]Bogus](https://github.com/bchavez/Bogus) and Auto Bogus come in handy. They both generate semi random test data that you can use to populate whatever method you've decided to use. You can setup rules so for specific fields, they have built in generators for common things like names and addresses. Auto Bogus can be used to populate large/complicated objects with data automatically (it can be slow if you don't use .WithRecursiveDepth() or.WithTreeDepth() )

Bogus - For creating fake data Verify - Snapshot testing for .NET MELT - For testing ILogger usage Stryker - Mutation Testing for .NET TestContainers - run docker programmatically in integration tests

To keep things interesting Bogus library is used to create a Person instance.

Usage with mocked data using Bogus NuGet package.

I would say the issue is either a general issue with how Revit loads the addin, or maybe an issue with conflicts in your transitive dependencies. You can do some tests to try to figure out which. Try making a barebones Revit addin that uses a library that has no dependencies and isn't likely to be used in Revit. I'd suggest Bogus, you can use it generate a few pieces of test data and log them/display in the UI/whatever. If that works, then it would appear that Revit is fine with your addin having dependencies (which I would expect).