Not moq methods with generic type

[shustrenko]

trafficstars

var connection = new Mock<IDbConnection>();

    var expected = new[]
    {
        new ComplexType { StringProperty = "String1", IntegerProperty = 7 }
    };

connection.SetupDapper(c => c.Query<ComplexType>(It.IsAny<string>(), null, null, true, null, null)) .Returns(expected);

////actual  will not null
var actual = connection.Object.Query<ComplexType>("", null, null, true, null, null);
   
////Now try moq Query with any new type
    connection.SetupDapper(c => c.Query<NewTestType>(It.IsAny<string>(), null, null, true, null, null)) .Returns(new [] { new NewTestType()} );

////actual  will be null
actual = connection.Object.Query<ComplexType>("", null, null, true, null, null)

[smokedlinq]

As I understand the problem and current limitations of the library, this isn't possible as the IDbConnection.CreateCommand() is replaced with each invocation of SetupDapper.

[jerone]

Possible duplicate of https://github.com/UnoSD/Moq.Dapper/issues/28

[IanKeefer]

I'm seeing the same results as of 5/21/2020. Has anyone written a work around or figured anything out?

Thanks

[jhgoodwin]

I haven't needed to rebuild it for a while, so the build badge is showing not built, but it's on nuget: https://github.com/jhgoodwin/FakeDbProvider

The notion is you just swap the db provider out for one you control, then you can fake by injection of your own behaviors for the db provider, rather than making elaborate wrappers for dapper.

If you feel this was unhelpful, or encounter any bugs in the library, be sure to let me know. If you'd rather fork it/fix it yourself, that works too. The code is quite tiny. I took it from Microsoft's EF library which doesn't seem to publish this part as a separate library, then fixed it up some so it'd would be more friendly to testing by stubbing out more DB related properties.

[yogeshk97]

Is there any update on this issue please? This hack is not working for me @jhgoodwin

    _mockIDbConnection
       .SetupDapperAsync(c => c.QueryAsync<ComboDishListModel>(
           It.IsAny<string>(), // You can specify the exact SQL query if needed
           It.IsAny<object>(),  // You can specify the expected parameters if needed
           It.IsAny<IDbTransaction>(),
           It.IsAny<int?>(),
           It.IsAny<CommandType?>()))
       .ReturnsAsync(comboDishListModels); // Provide the expected result

    _mockIDbConnection

.SetupDapperAsync(c => c.QueryAsync<OrderViewModel>( It.IsAny(), new { command.OrderId, command.UserId }, It.IsAny<IDbTransaction>(), It.IsAny<int?>(), It.IsAny<CommandType?>())) .ReturnsAsync(ordersResult);

When apply the second setup, it overrides the first mock setup, even if T is different

[jhgoodwin]

@yogeshk97 which hack? With full respect to the effort put into this project, I found it easier to make a fake DB provider than to use mocks.