Here are some of the questions you've asked. Ask more.
As you may know creating Unit Tests is a laborious part of development and in TDD (Test Driven Development) up to 50% of a programmer's job is writing the Unit Tests. Unit Tests are classically separated into three parts Arrange, Act and Assert. The Arrange portion is the largest part of a unit test and it sets up all the preconditions to a test, mocking all the data that is going to be acted upon in the test. The Act portion of an Unit Test is usually one line and activates the portion of code being tested, passing in that data. And finally the Assert portion of the test takes the results of the Act portion and verifies that it met expectations ( can be zero lines when just making sure there is no error).
ErrorUnit automatically writes the Arrange, and Act parts of the unit test, meaning it automates over 2/3rds of the task of creating a unit test!
It does this by integrating with the application's IoC (Inversion of Control) / DI ( Dependency Injection) library, or integrating into a MVC / Web API applications control filters, or using an AOP ( Aspect-Oriented Programming) library. Then when a programmer is debugging an application they can pause the program and create a Unit test for that code; ErrorUnit also acts as an error logger formatter, logging errors in any environment for conversion into Unit tests (hence its name). These Unit Tests contain not only the parameters that called methods, but the variables in each class, and the data accessed so far by EF (Entity Framework) from the database.
The ability to "Mock" Entity Framework is a killer feature as developers have struggled and have failed to mock it, rendering unit testing EF calls nearly impossible; not so with ErrorUnit.
ErrorUnit's standing overhead is minimal until an app errors it's just duplicate memory pointers ( not duplicate memory allocations) to all the classes/method arguments. The main determination on ErrorUnit's performance is your IoC library's interception performance/overhead. An alternate to using an IOC library (performance measured in milliseconds) is to use an AOP library (performance measured in nanoseconds ); for example we are compatible with PostSharp a performance hit is taken at compile time but the minimal possible at run time.
When there is an error the performance is dependent on the serialization library used. ErrorUnit was developed with Newtonsoft for serialization as that's the most supported library. ErrorUnit can be extended to use other serializers however current EF serialization is fully dependent on Newtonsoft and not abstracted for use with other serializers. Let us know, if this is something you want.
ErrorUnit depending on what you set up, can create UnitTests for various endpoints; MVC and Web Api Controller end points, what methods you manage with your IOC library, Or if you want to be able to create Unit Tests against all methods in your assembly/call stack, you need to use an AOP library; for example we are compatible with PostSharp
ErrorUnit is compatible with many libraries, here are the compatibility libraries we have open sourced;
SimpleInjector IOC library - available via nuget
Elmah error logging library - available via nuget
PostSharp AOP library - available via nuget
Autofac IOC library - available via nuget
Request / Send us more ...
ErrorUnit hashes the error message and the stack-trace to create an id for the error (and this hash will be more accurate if you include a pdb file so that line numbers are in the stack-trace). ErrorUnit will not create another unit test with the same hash id in the file name; renaming the unit test file will allow a new unit test to be created if an error with same fingerprint is occurring.
ErrorUnit will only go a month back in time in looking for errors to create unit tests for.