Part 11: Testing Strategies - Guaranteeing Rock-Solid Workflows

In the world of workflow automation, the cost of failure is high. A bug in a workflow can lead to lost data, broken integrations, or halted business processes. To prevent this, we have built a comprehensive testing strategy for Vyshyvanka that covers every layer — from isolated unit tests to full API integration tests.

The Philosophy: Testable by Design

Before we write a single test, we ensure our code is testable. We accomplish this by:

• Injecting dependencies (like HttpClient or ICredentialProvider) into constructors
• Using interfaces everywhere so we can substitute real implementations in tests
• Keeping node logic pure — given input and configuration, produce output

This simple architectural choice allows us to easily swap real services for test doubles.

Our Testing Stack

Tool	Purpose
xUnit	Test framework with async support
AwesomeAssertions	Fluent assertion library (.Should().Be(...))
NSubstitute	Interface mocking (Substitute.For<IService>())
CsCheck	Property-based testing for validation and serialization
bUnit	Blazor component testing
WebApplicationFactory	Full API integration tests

Example: Testing a Node

Let us look at how we test the HttpRequestNode. We do not make real network calls — we inject a custom MockHttpHandler that returns preconfigured responses:

public class HttpRequestNodeTests
{
    private static ExecutionContext CreateContext() =>
        new(Guid.NewGuid(), Guid.NewGuid(), NullCredentialProvider.Instance);

    private static HttpRequestNode CreateNodeWithHandler(HttpMessageHandler handler)
    {
        var client = new HttpClient(handler);
        return new HttpRequestNode(client);
    }

    [Fact]
    public async Task WhenGetRequestSucceedsThenReturnsSuccessWithResponseData()
    {
        var handler = new MockHttpHandler(new HttpResponseMessage(HttpStatusCode.OK)
        {
            Content = new StringContent(
                """{"message":"hello"}""",
                Encoding.UTF8,
                "application/json")
        });
        var sut = CreateNodeWithHandler(handler);
        var config = JsonSerializer.SerializeToElement(new
        {
            url = "https://api.example.com/data",
            method = "GET"
        });
        var input = new NodeInput { Data = default, Configuration = config };
        var context = CreateContext();

        var result = await sut.ExecuteAsync(input, context);

        result.Success.Should().BeTrue();
        result.Data.GetProperty("statusCode").GetInt32().Should().Be(200);
    }
}

Key patterns here:

• MockHttpHandler is a custom HttpMessageHandler that captures requests and returns preset responses.
• NullCredentialProvider.Instance provides a no-op credential provider for tests that don't need auth.
• Configuration is passed as JsonElement — matching exactly how the engine delivers it.
• Assertions use AwesomeAssertions' fluent syntax.

Mocking with NSubstitute

For services behind interfaces, we use NSubstitute. Here is how we test the PluginLoadingService:

public class PluginLoadingServiceTests
{
    private readonly IPluginLoader _pluginLoader = Substitute.For<IPluginLoader>();
    private readonly IPluginValidator _pluginValidator = Substitute.For<IPluginValidator>();
    private readonly INodeRegistry _nodeRegistry = Substitute.For<INodeRegistry>();
    private readonly IPackageCache _packageCache = Substitute.For<IPackageCache>();
    private readonly PluginLoadingService _sut;

    public PluginLoadingServiceTests()
    {
        _sut = new PluginLoadingService(
            _pluginLoader, _pluginValidator, _nodeRegistry, _packageCache);
    }

    [Fact]
    public async Task WhenPluginLoadsSuccessfullyThenRegistersNodes()
    {
        var assembly = typeof(PluginLoadingServiceTests).Assembly;
        _pluginLoader.TryLoadAssembly(Arg.Any<string>())
            .Returns(assembly);
        _pluginValidator.ValidatePlugin(assembly)
            .Returns(new PluginValidationResult { IsValid = true });

        var result = await _sut.LoadAndValidatePluginsAsync(
            "test-pkg", "1.0.0", "/install/path");

        result.Failure.Should().BeNull();
        _nodeRegistry.Received(1).RegisterFromAssembly(assembly);
    }
}

NSubstitute gives us:

• Substitute.For<T>() — creates a test double for any interface
• Arg.Any<T>() — matches any argument
• .Returns(value) — configures return values
• .Received(n) — verifies a method was called n times

Property-Based Testing with CsCheck

For logic that should hold true for all inputs (not just hand-picked examples), we use CsCheck:

[Fact]
public void WhenSerializedThenDeserializationRoundTrips()
{
    Gen.String.Sample(original =>
    {
        var json = JsonSerializer.Serialize(original);
        var result = JsonSerializer.Deserialize<string>(json);
        Assert.Equal(original, result);
    });
}

[Fact]
public void WhenWorkflowIdGeneratedThenAlwaysValid()
{
    Gen.Guid.Sample(id =>
    {
        id.Should().NotBe(Guid.Empty);
        Guid.TryParse(id.ToString(), out _).Should().BeTrue();
    });
}

CsCheck generates hundreds of random inputs and verifies your invariants hold for all of them. We use this extensively for:

• Serialization round-trips
• Expression evaluator edge cases
• Validation logic completeness

Integration Tests

For end-to-end API testing, we use WebApplicationFactory:

public class ExecutionApiTests : IClassFixture<WebApplicationFactory<Program>>
{
    private readonly HttpClient _client;

    public ExecutionApiTests(WebApplicationFactory<Program> factory)
    {
        _client = factory.CreateClient();
    }

    [Fact]
    public async Task WhenWorkflowNotFoundThenReturns404()
    {
        var request = new { workflowId = Guid.NewGuid() };
        var response = await _client.PostAsJsonAsync("/api/execution", request);

        response.StatusCode.Should().Be(HttpStatusCode.NotFound);
    }
}

This spins up the full ASP.NET Core pipeline in-process — middleware, controllers, DI, database — giving us confidence that the entire stack works together.

Test Organization

All tests live in Vyshyvanka.Tests/, organized by type:

tests/Vyshyvanka.Tests/
├── Unit/                  # Isolated tests, no I/O
│   ├── Nodes/            # Node-specific tests
│   ├── Components/       # Blazor component tests (bUnit)
│   └── ...
├── Property/             # CsCheck property-based tests
├── Integration/          # WebApplicationFactory tests
│   └── Fixtures/         # Shared test fixtures
└── E2E/                  # End-to-end scenario tests

Test Naming Convention

We follow the pattern When{Condition}Then{ExpectedResult}:

WhenWorkflowHasNoTriggerThenValidationFails()
WhenGetRequestSucceedsThenReturnsSuccessWithResponseData()
WhenPluginValidationFailsThenReturnsError()

This makes test output self-documenting — you can read the test names as a specification of the system's behavior.

The Benefits

1. Speed: Unit tests run in milliseconds. We can run the full suite on every commit.
2. Confidence: By mocking external dependencies, we verify our code's logic in isolation.
3. Documentation: Tests are the ultimate specification — they show exactly how every component behaves under specific conditions.
4. Regression Protection: Property-based tests catch edge cases that hand-written tests miss.

Testing is not a chore; it is a safety net. By making our nodes modular, injecting our dependencies, and rigorously testing every layer, we ensure that Vyshyvanka remains as reliable as the systems it automates.

In the next part, we will discuss Part 12: Performance Optimization - High-throughput processing and concurrency. Stay tuned!

---

Check out the project source code here: https://github.com/homolibere/Vyshyvanka