Skip to content

What's supported

Jump to bottom
Simon Laing edited this page Aug 28, 2019 · 19 revisions

Setup of any Dapper method, listed below. Verification of any Dapper method, listed below. No need to setup a Dapper call (no data will be returned from the call, but it will be executed) All the power, and familiar syntax of Moq.

Methods

  • Execute & ExecuteAsync
  • Query<T> & QueryAsync<T>
  • QuerySingle<T> & QuerySingleAsync<T>
  • QuerySingleOrDefault<T> & QuerySingleOrDefaultAsync<T>
  • QueryFirst<T> & QueryFirstAsync<T>
  • QueryFirstOrDefault<T> & QueryFirstOrDefaultAsync<T>
  • ExecuteScalar, ExecuteScalar<T>, ExecuteScalarAsync and ExecuteScalarAsync<T>

Properties

  • SQL (case insensitive, ignores empty lines & leading/trailing white-space)
  • Parameters
  • Transaction
  • CommandType
  • CommandTimeout

Known issues

1.1 Running the same SQL (and parameters) but for different return types can cause a conflict.

E.g.

conn.Query<Car>("select * from vehicles where id = @id", new { id = 1});
conn.Query<Truck>("select * from vehicles where id = @id", new { id = 1});

Set Settings.Default.ResetDapperCachePerCommand to true to solve this. Note this is not thread safe, there is no other known solution to this circumstance at present. This setting can be defined statically via Settings.Default or supplied via an instance of the Settings provided to the MockDbConnection

1.2 Some argument values aren't correlated

The following arguments cannot currently be reverse engineered therefore cannot be accurately asserted:

  • buffered
  • map
  • types
  • splitOn

Issues exist to resolve these where possible, but currently there is no solution except to not expect/verify these values, i.e use It.IsAny<>() for now.

Clone this wiki locally