Fluent Assertions VS Bogus

FluentAssertions para Asserts muy flexibles y entendibles

https://www.nuget.org/packages/Newtonsoft.Json/ https://www.nuget.org/packages/AutoMapper/ https://www.nuget.org/packages/Dapper/ https://www.nuget.org/packages/FluentValidation/ https://www.nuget.org/packages/FluentAssertions/ https://www.nuget.org/packages/NUnit/ https://www.nuget.org/packages/xunit/ https://www.nuget.org/packages/YamlDotNet/ https://www.nuget.org/packages/Moq/ That is simply not true. Mature c# projects purposely maintain no downstream dependencies and is they do, it's to a major reputable lib. See for yourself - these are staple third party packages commonly used. Anything dependency starting with System or NETStandard is Microsoft maintained.

FluentAssertions is one of the most popular (over 66 million downloads on Nuget) .NET library that contains a large collection of .NET extension methods that allow .NET developers to write unit tests using a fluent syntax which is very easy to read and write and clearly shows the intent of the unit test. The library has extension methods to test almost everything related to .NET such as Strings, Booleans, Dates, Guids, Collections, Exceptions, and even Nullable Types. You can add this library to your unit test projects via Nuget package manager and start using this library in few minutes.

I love fluency. I myself work on a package for fluent programming. I recommend you using FluentAssertions for tests though. Nonetheless, keep working! Starred your repo.

For example, all tests below this line are written in Honk# + FluentAssertions (the latter is an example of a library which also provides a lot of fluent methods for xUnit to perform assertions). Soon I'll be moving more of its (AngouriMath's) code to this style, as long as it doesn't harm readability and performance.

fluentassertions / fluentassertions

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).