Please provide public getter to access DynamicParameters' parameters dictionary object

[ericlau-solid]

I am using dapper and it is really frustrating that I have no way of mocking a dapper .execute or .query call and write tests on the parameters being sent to those method calls. Get<> method does not work with a mocked IDbConnection, and I am not the only one with this issue: http://stackoverflow.com/questions/29829209/machinespecs-unit-testing-dapper

Please add a getter to the parameters, or allow a way to get not just the param names, but also the input param values.

[johandanforth]

I've never tried this myself because mocking system.data is usually too much work to be worth it I think :) But having said that - I can't see why the Get<> wouldn't work. What kind of error do you get and could you provide a simple working example please?

[ericlau-solid]

I would never suggest we mock system.data. but that is not what this is
about.

I am writing a repository class, and depending on data, I have to set sproc
params differently. I want to unit test if param setup is correct. In unit
testing, get method does not error, but does not get expected values, thus
failing unit tests.
On Jun 20, 2015 06:58, "Johan Danforth" notifications@github.com wrote:

I've never tried this myself because mocking system.data is usually too
much work to be worth it I think :) But having said that - I can't see why
the Get<> wouldn't work. What kind of error do you get and could you
provide a simple working example please?

—
Reply to this email directly or view it on GitHub
#304 (comment)
.

[johandanforth]

I could still use some sample of how you mock the dbconnection + dbcommand for me to test this out and come with a good solution. I've tried mocking dbcommand with MOQ but it didn't went well... :)

[ericlau-solid]

I have a sample .sln to provide you, but message size is too big. Need
another way to send you the zipped file (10mb). Please provide a means to
send this.

On Sun, Jun 21, 2015 at 3:10 AM, Johan Danforth notifications@github.com
wrote:

I could still use some sample of how you mock the dbconnection + dbcommand
for me to test this out and come with a good solution. I've tried mocking
dbcommand with MOQ but it didn't went well... :)

—
Reply to this email directly or view it on GitHub
#304 (comment)
.

Eric Lau from Gmail account.

[johandanforth]

Wow, that big even with /bin and /obj removed from the zip? Perhaps you can place it on Google Drive or Microsoft Onedrive and mail me a readonly-link? you reach me at johan_danforth on hotmail

[johandanforth]

You wrote:

I am writing a repository class, and depending on data, I have to set sproc
params differently. I want to unit test if param setup is correct. In unit
testing, get method does not error, but does not get expected values, thus
failing unit tests.

Can't you refactor out the code that do the sproc parameter settings in a separate class/method and test just that?

[ericlau-solid]

I could, but it is a total workaround in which the only reason for doing so
is because dapper dynamicparameters do not have public getter. Another
total workaround is to wrap dynamic parameters. Both add bloat to a code
that a one getter will resolve.

Eric
On Jun 25, 2015 03:01, "Johan Danforth" notifications@github.com wrote:

You wrote:

I am writing a repository class, and depending on data, I have to set sproc
params differently. I want to unit test if param setup is correct. In unit
testing, get method does not error, but does not get expected values, thus
failing unit tests.

Can't you refactor out the code that do the sproc parameter settings in a
separate class/method and test just that?

—
Reply to this email directly or view it on GitHub
#304 (comment)
.

[ericlau-solid]

Johan, I just sent you a zipped file at the address you requested. Thanks.

[NickCraver]

@mgravell thoughts on this? I also considered implementing IEnumerable<ParamInfo> with a corresponding .Add() handling cleaning and default sets to be sure which would allow for collection initializers usage, but we'd have to expose ParamInfo to make this possible. I think we can do that safely, but I'm not 100% sure we should (with respect to mutability).