Cleaning up documentation

Author: oswaldsql

docs/ADR/README.md

@@ -4,7 +4,7 @@ Architecture Decision Records (ADRs) are documents that capture important archit
 
 All the ADRs have been approved and are considered final decisions for the project.
 
-## General ADRs
+## General ADRs [TL;DR](general/TLDR.md)
 
 - [Do We __Really__ Need a New Mocking Framework?](general/DoWeNeedANewMockingFramework.md) - Deciding whether to build a new mocking framework.
 - [Matching Target API in Mock API](general/MatchingTargetApi.md) - Ensures the mock API closely mirrors the target API.
@@ -13,27 +13,16 @@ All the ADRs have been approved and are considered final decisions for the proje
 - [No Dependencies to Shared Libraries](general/NoDependencies.md) - Avoid dependencies on shared libraries.
 - [Documentation and Examples](general/DocumentationAndExamples.md) - Approach to documentation and examples for the framework.
 - [Logging and Debugging](general/LoggingAndDebugging.md) - Approach to logging and debugging within the framework.
-- [Creating Mocks](general/CreatingMocks.md) - Decision on how to create mocks in the framework.
 
-## Feature Specific ADRs
+## Feature Specific ADRs [TL;DR](feature/TLDR.md)
 
-- [Support for Classes and Interfaces](feature/SupportForClassesAndInterfaces.md) - Decision on supporting classes and interfaces in the mocking framework.
+- [Support for Classes and Interfaces](feature/SupportForClassesAndInterfaces.md) - How should classes and interfaces be supported.
 - [Support for Constructors](feature/SupportForConstructors.md) - Decision on supporting constructors in the mocking framework.
+- [Creating Mocks](feature/CreatingMocks.md) - Decision on how to create mocks in the framework.
 - [Support for Methods](feature/SupportForMethods.md) - Decision on supporting methods in the mocking framework.
 - [Support for Properties](feature/SupportForProperties.md) - Decision on supporting properties in the mocking framework.
 - [Support for Events](feature/SupportForEvents.md) - Decision on supporting events in the mocking framework.
 - [Support for Indexers](feature/SupportForIndexers.md) - Decision on supporting indexers in the mocking framework.
-- Special cases
-  - [Allowing Skipping Arguments in Mock Setup](feature/SupportSkippingArguments.md) - Allows skipping arguments in mock setups for flexibility.
-  - [Support for Protected Methods](feature/SupportingProtectedMethods.md) - Decision on whether to support mocking protected methods.
-  - [Support for Generic Methods (WIP)](feature/SupportForGenericMethods.md) - Decision on supporting generic methods in the mocking framework.
-  - [Support for Asynchronous Methods (WIP)](feature/SupportForAsynchronousMethods.md) - Handling asynchronous methods in the mocking framework.
-  - [Support for Virtual Methods (WIP)](feature/SupportForVirtualMethods.md) - Decision on supporting virtual methods in the mocking framework.
-  - [Support for Overloads (WIP)](feature/SupportForOverloads.md) - Decision on supporting method overloads in the mocking framework.
-  - [Support for Out and Ref Parameters (WIP)](feature/SupportForOutAndRefParameters.md) - Decision on supporting out and ref parameters in the mocking framework.
-  - [Support for Internal Methods (WIP)](feature/SupportForInternalMethods.md) - Decision on supporting internal methods in the mocking framework.
-  - [Support for Abstract Classes (WIP)](feature/SupportForAbstractClasses.md) - Decision on supporting abstract classes in the mocking framework.
-  - [Support for Delegates (WIP)](feature/SupportForDelegates.md) - Decision on supporting delegates in the mocking framework.
 
 ## Unsupported Features
 

docs/ADR/general/CreatingMocks.md docs/ADR/feature/CreatingMocks.mddocs/ADR/general/CreatingMocks.md renamed to docs/ADR/feature/CreatingMocks.md

@@ -7,6 +7,7 @@ In the MiniMock framework, there is a need to establish a standardized approach
 ## Decision
 
 Mocks will be created using a mock factory. The mock factory will provide a centralized and consistent way to create and configure mocks, ensuring that all mocks are created following the same process and standards.
+The constructors of the mock object will remain accessible but should only be used for limited purposes.  
 
 ## Consequences
 

docs/ADR/feature/SupportForAbstractClasses.md

@@ -2,29 +2,33 @@
 
 ## Context
 
-In the MiniMock framework, there is a need to determine the scope of support for mocking constructors. Initially, the framework will support only classes with parameterless constructors. 
-This decision simplifies the initial implementation and allows for a gradual introduction of more complex constructor support.
+In the MiniMock framework, there is a need to determine the scope of support for mocking constructors.
 
 ## Decision
 
-The MiniMock framework will initially support mocking only classes with parameterless constructors. 
-A plan for adding support for classes with parameterized constructors is being developed and will be implemented in future iterations.
+All constructors with the supported access level should be accessible. If no constructor exists, a parameterless constructor is created.
+A factory for each option should be created.
 
-Since the main focus of the framework is to provide a simple and easy-to-use mocking solution for interfaces and classes, 
-the decision to start with parameterless constructors aligns with this goal. See ADR [Support For Classes and Interfaces](SupportForClassesAndInterfaces.md) for more information.
+If only internal or private constructors exist, the class is not generated and a warning is registered.
+
+Additionally, the framework should support the following:
+
+- **Parameterized Constructors**: Allow mocking of constructors with parameters, providing flexibility for more complex scenarios.
+- **Constructor Overloads**: Support multiple constructors with different parameter lists.
+- **Dependency Injection**: Enable mocking of constructors that use dependency injection, ensuring compatibility with modern design patterns.
 
 ## Consequences
 
 ### Positive:
 
 - **Simplicity**: Simplifies the initial implementation by focusing on parameterless constructors.
-- **Incremental Development**: Allows for a phased approach to adding more complex constructor support.
-- **Usability**: Provides immediate value by supporting a common use case.
+- **Flexibility**: Supporting parameterized constructors and overloads provides more flexibility for developers.
+- **Compatibility**: Ensures compatibility with dependency injection, making the framework more versatile.
 
 ### Negative:
 
-- **Limited Scope**: Initial support is limited to classes with parameterless constructors, which may not cover all use cases.
-- **Future Work**: Additional effort will be required to implement support for parameterized constructors.
+- **Complexity**: Adding support for parameterized constructors and overloads increases the complexity of the framework.
+- **Maintenance**: Requires ongoing maintenance to ensure that constructor mocking remains robust and up-to-date.
 
 ---
 

docs/ADR/feature/SupportForAsynchronousMethods.md

@@ -2,7 +2,14 @@
 
 ## Context
 
-In the MiniMock framework, there is a need to determine the scope of support for mocking methods. Supporting all standard ways of creating methods is essential to ensure the framework's flexibility and usability. However, there are currently issues with supporting methods that return `ref` values, which need to be addressed.
+In the MiniMock framework, there is a need to determine the scope of support for mocking methods. Supporting all standard ways of creating methods is essential to ensure the framework's 
+flexibility and usability. 
+
+The following type of methods must be supported
+- __Asynchronous__ with Task<>, Task, CancellationToken  
+- __Overloaded__ methods in a way that keeps the required effort to setup the mock to a minimum.
+- __Generic__ Including the 'where' __constraints__.
+- __Out__ and __ref__ attributes on the method parameters.
 
 ## Decision
 
@@ -18,7 +25,20 @@ Methods must be mockable using the following parameters
 
 if none of the above parameters are provided, calling the method must throw a InvalidOperationException with a message in the form "The method '__[method name]__' in '__[mocked class]__' is not explicitly mocked.".
 
-Special cases like [Overloads], [Generic Methods] and [Async Methods] have dedicated ADRs.
+__Asynchronous__ methods are supported. Helper methods are provided to simplify the testing of asynchronous methods. Overloads of the following helper methods are added
+
+- Return : Allows for returning either a Task object or the object to be wrapped in the task object.
+- ReturnValues : Allows for returning either a sequence of Task objects or a sequence of objects to be wrapped in task objects.
+- () : Methods returning Task can also use the empty delegate.
+
+__Overloaded__ methods can either be mocked explicitly by using `Call` or collectively using the following 
+
+- Throw : An exception to be thrown when calling any of the overwritten methods.
+- Return : A value to be returned when a method with that return type is called.
+- ReturnValues : A sequence of values to be returned when a method with those return types is called multiple times.
+- () : Methods returning `void` or `Task` can be mocked using an empty delegate.
+
+Generic methods are supported. The generic type is passed as a type parameter to the 'call' labmda method.
 
 ## Consequences