Feature: add fake data module

[Namoshek]

This pull request introduces a new "Fake Data" module to the solution, enabling the generation of realistic test data for workflows using the Bogus library. The module provides configurable activities for generating collections of fake users, persons, products, and orders, along with supporting models, features, and extension methods for easy integration. Solution and project files are updated to include the module and its unit tests.

Solution and Project Structure Updates

• Updated the solution file to include the new Elsa.FakeData and Elsa.FakeData.UnitTests projects, their folder structure, build configurations, and project dependencies.

Fake Data Module Implementation

• Added the new Elsa.FakeData project with activities to generate fake data for users, persons, products, and orders, leveraging the Bogus library for data generation.
• Implemented core activities: GenerateFakeUsers, GenerateFakePersons, GenerateFakeProducts, and GenerateFakeOrders, each producing collections of strongly-typed fake records.
• Defined supporting models: FakeUser, FakePerson, FakeProduct, and FakeOrder to represent generated data records.

Tests:

• Added a comprehensive test suite in Elsa.FakeData.UnitTests for all added activities.

Example Usage:

new GenerateFakeOrders
{
    Count = new Input<int>(100),
    Locale = new Input<string>("de"),
    Seed = new Input<int?>(42),
}

[greptile-apps]

Greptile Summary

This PR introduces a new Elsa.FakeData module that provides four workflow activities — GenerateFakeUsers, GenerateFakePersons, GenerateFakeProducts, and GenerateFakeOrders — backed by the Bogus library for realistic synthetic data generation. The module follows the established Elsa extension pattern (feature registration, module extension method, [Activity] attributes) and is accompanied by a solid unit test suite covering count, locale, seed, and property-population scenarios. The workbench projects are updated to register the module via UseFakeData().

Key findings:

• Non-deterministic DateOfBirth with seeded GenerateFakePersons: DateTime.Now.AddYears(-18) is evaluated at execution time, so the date range shifts daily, producing different absolute birth dates even with the same seed. The determinism test for persons does not assert DateOfBirth, so this slips past the test suite.
• Unguarded negative Count: Bogus throws an ArgumentException for negative counts, but there is no early validation in GenerateFakeDataActivity.ExecuteAsync. A workflow that receives a negative value at runtime will produce an uncaught exception.
• Unnecessary Microsoft.Extensions.Http reference: The project file includes Microsoft.Extensions.Http, but no HTTP client functionality is used anywhere in the module — likely copy-pasted from another project file.
• Unused lambda parameters: Several RuleFor lambdas in GenerateFakeUsers and GenerateFakePersons declare a second parameter (u/p) that is never referenced, which may produce compiler warnings.
• Duplicate solution folder names: Two solution folders both named "fakedata" are added to the .sln file; while technically valid when properly nested, this can cause confusion in Visual Studio's Solution Explorer.

Confidence Score: 3/5

• Safe to merge after addressing the negative-count exception and the DateTime.Now determinism issue in GenerateFakePersons.
• The module is well-structured and the overall approach is sound, but two logic-level issues — missing input validation for negative counts and broken seeded-determinism due to DateTime.Now — could cause runtime failures or silently incorrect behaviour in production workflows. These warrant fixing before merge.
• src/modules/fakedata/Elsa.FakeData/Activities/GenerateFakeDataActivity.cs (missing negative-count guard) and src/modules/fakedata/Elsa.FakeData/Activities/GenerateFakePersons.cs (DateTime.Now breaks determinism).

Important Files Changed

Filename	Overview
src/modules/fakedata/Elsa.FakeData/Activities/GenerateFakeDataActivity.cs	Base activity for fake data generation; missing validation for negative Count values which causes an unhandled exception from Bogus.
src/modules/fakedata/Elsa.FakeData/Activities/GenerateFakePersons.cs	Generates fake person records; DateTime.Now reference in DateOfBirth rule breaks determinism even when a seed is provided, and an unused lambda parameter may trigger a compiler warning.
src/modules/fakedata/Elsa.FakeData/Activities/GenerateFakeUsers.cs	Generates fake user records; two lambdas declare an unused second parameter u, which may produce compiler warnings.
src/modules/fakedata/Elsa.FakeData/Activities/GenerateFakeOrders.cs	Generates fake order records with correctly derived Tax and Total fields; clean implementation with no issues found.
src/modules/fakedata/Elsa.FakeData/Activities/GenerateFakeProducts.cs	Generates fake product records; straightforward and correct implementation.
src/modules/fakedata/Elsa.FakeData/Elsa.FakeData.csproj	Project file includes an unnecessary Microsoft.Extensions.Http reference that is not used anywhere in the module.
src/modules/fakedata/Elsa.FakeData/Features/FakeDataFeature.cs	Minimal feature registration that scans the assembly for activity types; follows established patterns correctly.
test/modules/fakedata/Elsa.FakeData.UnitTests/Activities/GenerateFakePersonsTests.cs	Good test coverage, but the determinism test does not assert DateOfBirth, masking the DateTime.Now non-determinism issue in the activity.
Elsa.Extensions.sln	Adds two solution folders both named "fakedata" (for src and test), which may cause confusion in solution explorer tooling, though functionally valid when properly nested.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Workflow Engine] -->|calls| B[GenerateFakeDataActivity<T>]
    B -->|reads| C[Count Input]
    B -->|reads| D[Locale Input]
    B -->|reads| E[Seed Input]
    B -->|creates| F[Faker<T> via CreateFaker]
    F -->|seed != null| G[UseSeed]
    F -->|seed == null| H[Random seed]
    G --> I[faker.Generate count]
    H --> I
    I -->|sets| J[Result Output T array]

    B --> K1[GenerateFakeUsers]
    B --> K2[GenerateFakePersons]
    B --> K3[GenerateFakeProducts]
    B --> K4[GenerateFakeOrders]

    K1 -->|produces| L1[FakeUser records]
    K2 -->|produces| L2[FakePerson records]
    K3 -->|produces| L3[FakeProduct records]
    K4 -->|produces| L4[FakeOrder records]

    M[UseFakeData extension] -->|registers| N[FakeDataFeature]
    N -->|AddActivitiesFrom| K1
    N -->|AddActivitiesFrom| K2
    N -->|AddActivitiesFrom| K3
    N -->|AddActivitiesFrom| K4

Loading

_{Last reviewed commit: 6d57981}

[greptile-apps]

_{25 files reviewed, 5 comments}

_{Edit Code Review Agent Settings | Greptile}

[greptile-apps]

Additional Comments (1)

Elsa.Extensions.sln
Two solution folders share the name "fakedata"

Two separate solution folders are both named "fakedata" (GUIDs {3A829F79...} and {DCDBD383...}). While this is valid in .sln files (they'll be nested under different parent folders in the NestedProjects section), it can cause confusion in Visual Studio's Solution Explorer and in tooling that matches folders by name. Consider naming them "fakedata (src)" / "fakedata (test)", or verify that the nesting section correctly places them under the appropriate parent modules and test containers so the hierarchy is unambiguous.