You cannot mock or derive from SqlDataReader
. To mock it using something like Moq the library creates a derived type and then overrides the virtual members. If the type doesn't have a public constructor then you get the error you're seeing. SqlDataReader
has a single constructor and it is internal. Since it is internal you cannot derive from it and hence cannot mock it either. The only possible workaround that I'm aware of is to use a mocking library that doesn't use derived types and Moq isn't one of them.
Mocking calls to SQL is mostly a mute point anyway. There is really no unit test that you could create that would provide any level of confidence the code is working without actually talking to the SQL database. For example you could mock the running of a command in SQL but unless you also validated the SQL command (aka it is syntactically correct) then all you've really confirmed is that your code is calling a method on a type. If you need to unit test code against SQL then have your unit test target a SQL database, perhaps an embedded one using SQL CE or something.
The better approach is to generalize your code to use the more generic ADO.NET interfaces or base types from which SQL and other providers derive. Then you can more easily mock them and verify the general behavior of your code (but again, not really giving you validation of the actual calls). Having tried to mock the base Db-
types I can tell you it is very difficult to do with lots of extra code to write. Personally I would use the interfaces because at least that is less code to mock.