Mocking a return result set from SearchAsync where SearchResult only has an Internal Constructor

[ramonhenares]

I'm trying to mock Search/SearchAsync from the ISearchCommandsAsync/ISearchCommands/FT areas and am running into a problem when returning a resultset as the class SearchResult only has an internal constructor. What is the best method in returning a result set when mocking a Search done through IDatabase.FT().Search / IDatabase.FT().SearchAsync ?

[Pleo2]

With the current public API, there is no supported way to construct a realistic SearchResult directly in a consumer test. Its constructor is intentionally internal because it parses the raw Redis protocol response (source). Reflection or an uninitialized object would couple the test to implementation details and can silently create an invalid result.

The clean unit-testing boundary is to wrap NRedisStack in an application-owned interface and return your own result type:

public interface IProductSearch
{
    Task<IReadOnlyList<ProductHit>> SearchAsync(string query);
}

public sealed class RedisProductSearch : IProductSearch
{
    private readonly IDatabase _db;

    public RedisProductSearch(IDatabase db) => _db = db;

    public async Task<IReadOnlyList<ProductHit>> SearchAsync(string query)
    {
        var result = await _db.FT().SearchAsync("products", new Query(query));
        return result.Documents.Select(MapDocument).ToList();
    }
}

Mock IProductSearch in tests for the business/service layer. Test the small RedisProductSearch adapter with an integration test against Redis Stack (for example, a disposable Testcontainers instance), because that is where command encoding and response parsing are the behavior under test.

If direct construction is needed broadly, the library would need an explicit public factory/test builder; making the parsing constructor public would expose protocol-specific invariants that callers should not have to reproduce.