[nhusers] Custom User Type with IUserType

[TheNephalim]

I was writing some unit tests for a custom type and everything was fine
until I got to NullSafeSet:

public void NullSafeSet(DbCommand cmd, object value, int index,
ISessionImplementor session) {
if (value == null) {
((IDataParameter)cmd.Parameters[index]).Value =
DBNull.Value;
} else {
var yes = (bool)value;
((IDataParameter)cmd.Parameters[index]).Value = yes ? "Y" :
"N";
}
}

It appears that on change NH-3431 there was a mass replace of the usage of
System.Data classes to System.Data.Common classes. The code moved from
interfaces in the function signatures to concrete classes. This makes it
not possible to test this method, as far as I can tell, without actually
trying to instantiate an instance of a command to pass into the method.

Does anyone have an idea of why this choice was made? It is what it is at
this point. I'm just curious as to the reasoning.

- Robert

[Alexander Zaytsev]

DbCommand is an abstract class. It should be testable the same way as
the IDbCommand interface.

The reason to change is that interfaces are immutable (at least in
Microsoft's point of view on BCL) - once set it cannot have methods added
or removed. The abstract classes are more fluid and can have additional
methods (if the method itself is not abstract). The particular functions we
were interested from abstract classes are the *Async methods which were
added to the class hierarchy, but not to the interfaces.

Best Regards,
Alexander

Post by TheNephalim
I was writing some unit tests for a custom type and everything was fine
public void NullSafeSet(DbCommand cmd, object value, int index,
ISessionImplementor session) {
if (value == null) {
((IDataParameter)cmd.Parameters[index]).Value =
DBNull.Value;
} else {
var yes = (bool)value;
((IDataParameter)cmd.Parameters[index]).Value = yes ? "Y"
: "N";
}
}
It appears that on change NH-3431 there was a mass replace of the usage of
System.Data classes to System.Data.Common classes. The code moved from
interfaces in the function signatures to concrete classes. This makes it
not possible to test this method, as far as I can tell, without actually
trying to instantiate an instance of a command to pass into the method.
Does anyone have an idea of why this choice was made? It is what it is at
this point. I'm just curious as to the reasoning.
- Robert
--
You received this message because you are subscribed to the Google Groups "nhusers" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/group/nhusers.
For more options, visit https://groups.google.com/d/optout.

[Robert Eberhart]

Thank you for your response.

You are correct.

Upon reviewing your answer, the issue I'm having is less with DbCommand
than with the DbParameterCollection. I'm using Moq and when I try to
mock/fake the DbCommand and set up the DbParameterCollection using a
variety of standard techniques, Moq pitches a fit.

However, your answer combined with a review of the DbParameterCollection
class gave me an idea. I'm going to give it a shot and see if it works.

Sincerely,
Robert

Post by Alexander Zaytsev
DbCommand is an abstract class. It should be testable the same way as
the IDbCommand interface.
The reason to change is that interfaces are immutable (at least in
Microsoft's point of view on BCL) - once set it cannot have methods added
or removed. The abstract classes are more fluid and can have additional
methods (if the method itself is not abstract). The particular functions we
were interested from abstract classes are the *Async methods which were
added to the class hierarchy, but not to the interfaces.
Best Regards,
Alexander

Post by TheNephalim
I was writing some unit tests for a custom type and everything was fine
public void NullSafeSet(DbCommand cmd, object value, int index,
ISessionImplementor session) {
if (value == null) {
((IDataParameter)cmd.Parameters[index]).Value =
DBNull.Value;
} else {
var yes = (bool)value;
((IDataParameter)cmd.Parameters[index]).Value = yes ?
"Y" : "N";
}
}
It appears that on change NH-3431 there was a mass replace of the usage
of System.Data classes to System.Data.Common classes. The code moved from
interfaces in the function signatures to concrete classes. This makes it
not possible to test this method, as far as I can tell, without actually
trying to instantiate an instance of a command to pass into the method.
Does anyone have an idea of why this choice was made? It is what it is
at this point. I'm just curious as to the reasoning.
- Robert
--
You received this message because you are subscribed to the Google Groups
"nhusers" group.
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/group/nhusers.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the
Google Groups "nhusers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/
topic/nhusers/39RnNkXgz78/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
Visit this group at https://groups.google.com/group/nhusers.
For more options, visit https://groups.google.com/d/optout.

[Robert Eberhart]

Hello,

This may not matter to other people, but I wanted to place this here just
in case someone else has the same problem:

[Fact]
public void YesNoType_Returns_N_From_NullSafeSet() {
var sessionImplementor = new Mock<ISessionImplementor>();
var dbCommand = new Mock<DbCommand>();
var dbParameterCollection = new Mock<DbParameterCollection>();

var dbParameter = Mock.Of<DbParameter>();
dbParameter.Value = string.Empty;

dbParameterCollection.Protected()
.Setup<DbParameter>("GetParameter", new object[] {
It.IsAny<int>() }).Returns(dbParameter);

dbCommand.Protected()
.Setup<DbParameterCollection>("DbParameterCollection")
.Returns(dbParameterCollection.Object);

var type = new YesNoType();

type.NullSafeSet(dbCommand.Object, false, 0,
sessionImplementor.Object);
dbCommand.Object.Parameters[0].Value.ShouldBe("N");
}


I took a look at the DbParameterCollection and it has an abstract,
protected GetParameter method which I was able to setup.

Thanks again for your help on this issue.

Post by Robert Eberhart
Thank you for your response.
You are correct.
Upon reviewing your answer, the issue I'm having is less with DbCommand
than with the DbParameterCollection. I'm using Moq and when I try to
mock/fake the DbCommand and set up the DbParameterCollection using a
variety of standard techniques, Moq pitches a fit.
However, your answer combined with a review of the DbParameterCollection
class gave me an idea. I'm going to give it a shot and see if it works.
Sincerely,
Robert

Post by Alexander Zaytsev
DbCommand is an abstract class. It should be testable the same way as
the IDbCommand interface.
The reason to change is that interfaces are immutable (at least in
Microsoft's point of view on BCL) - once set it cannot have methods added
or removed. The abstract classes are more fluid and can have additional
methods (if the method itself is not abstract). The particular functions we
were interested from abstract classes are the *Async methods which were
added to the class hierarchy, but not to the interfaces.
Best Regards,
Alexander

Post by TheNephalim
I was writing some unit tests for a custom type and everything was fine
public void NullSafeSet(DbCommand cmd, object value, int index,
ISessionImplementor session) {
if (value == null) {
((IDataParameter)cmd.Parameters[index]).Value =
DBNull.Value;
} else {
var yes = (bool)value;
((IDataParameter)cmd.Parameters[index]).Value = yes ?
"Y" : "N";
}
}
It appears that on change NH-3431 there was a mass replace of the usage
of System.Data classes to System.Data.Common classes. The code moved from
interfaces in the function signatures to concrete classes. This makes it
not possible to test this method, as far as I can tell, without actually
trying to instantiate an instance of a command to pass into the method.
Does anyone have an idea of why this choice was made? It is what it is
at this point. I'm just curious as to the reasoning.
- Robert
--
You received this message because you are subscribed to the Google
Groups "nhusers" group.
To unsubscribe from this group and stop receiving emails from it, send
Visit this group at https://groups.google.com/group/nhusers.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the
Google Groups "nhusers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/to
pic/nhusers/39RnNkXgz78/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
Visit this group at https://groups.google.com/group/nhusers.
For more options, visit https://groups.google.com/d/optout.

[Roger Kratz]

IMHO, do not unit test/mock nhib types. Write integration tests for this instead.



From: ***@googlegroups.com [mailto:***@googlegroups.com] On Behalf Of Robert Eberhart
Sent: den 6 april 2018 19:50
To: ***@googlegroups.com
Subject: Re: [nhusers] Custom User Type with IUserType

Hello,

This may not matter to other people, but I wanted to place this here just in case someone else has the same problem:

[Fact]
public void YesNoType_Returns_N_From_NullSafeSet() {
var sessionImplementor = new Mock<ISessionImplementor>();
var dbCommand = new Mock<DbCommand>();
var dbParameterCollection = new Mock<DbParameterCollection>();

var dbParameter = Mock.Of<DbParameter>();
dbParameter.Value = string.Empty;

dbParameterCollection.Protected()
.Setup<DbParameter>("GetParameter", new object[] { It.IsAny<int>() }).Returns(dbParameter);

dbCommand.Protected()
.Setup<DbParameterCollection>("DbParameterCollection")
.Returns(dbParameterCollection.Object);

var type = new YesNoType();

type.NullSafeSet(dbCommand.Object, false, 0, sessionImplementor.Object);
dbCommand.Object.Parameters[0].Value.ShouldBe("N");
}


I took a look at the DbParameterCollection and it has an abstract, protected GetParameter method which I was able to setup.

Thanks again for your help on this issue.

2018-04-06 9:49 GMT-04:00 Robert Eberhart <***@gmail.com<mailto:***@gmail.com>>:
Thank you for your response.

You are correct.

Upon reviewing your answer, the issue I'm having is less with DbCommand than with the DbParameterCollection. I'm using Moq and when I try to mock/fake the DbCommand and set up the DbParameterCollection using a variety of standard techniques, Moq pitches a fit.

However, your answer combined with a review of the DbParameterCollection class gave me an idea. I'm going to give it a shot and see if it works.

Sincerely,
Robert

2018-04-05 20:38 GMT-04:00 Alexander Zaytsev <***@gmail.com<mailto:***@gmail.com>>:
DbCommand is an abstract class. It should be testable the same way as the IDbCommand interface.

The reason to change is that interfaces are immutable (at least in Microsoft's point of view on BCL) - once set it cannot have methods added or removed. The abstract classes are more fluid and can have additional methods (if the method itself is not abstract). The particular functions we were interested from abstract classes are the *Async methods which were added to the class hierarchy, but not to the interfaces.

Best Regards,
Alexander

On Fri, Apr 6, 2018 at 10:51 AM, TheNephalim <***@gmail.com<mailto:***@gmail.com>> wrote:
I was writing some unit tests for a custom type and everything was fine until I got to NullSafeSet:

public void NullSafeSet(DbCommand cmd, object value, int index, ISessionImplementor session) {
if (value == null) {
((IDataParameter)cmd.Parameters[index]).Value = DBNull.Value;
} else {
var yes = (bool)value;
((IDataParameter)cmd.Parameters[index]).Value = yes ? "Y" : "N";
}
}

It appears that on change NH-3431 there was a mass replace of the usage of System.Data classes to System.Data.Common classes. The code moved from interfaces in the function signatures to concrete classes. This makes it not possible to test this method, as far as I can tell, without actually trying to instantiate an instance of a command to pass into the method.

Does anyone have an idea of why this choice was made? It is what it is at this point. I'm just curious as to the reasoning.

- Robert
--
You received this message because you are subscribed to the Google Groups "nhusers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nhusers+***@googlegroups.com<mailto:nhusers+***@googlegroups.com>.
To post to this group, send email to ***@googlegroups.com<mailto:***@googlegroups.com>.
Visit this group at https://groups.google.com/group/nhusers<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fgroup%2Fnhusers&data=02%7C01%7Croger.kratz%40teleopti.com%7C6686e8253ac94f00033a08d59be6eafb%7C449a67e94f234e758bccf32dd77cefe0%7C0%7C1%7C636586338476016018&sdata=euT%2BbmiMmXBkYG0Q8PqbKmxQ0sEItM40sVHgBSk%2FUY4%3D&reserved=0>.
For more options, visit https://groups.google.com/d/optout<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Foptout&data=02%7C01%7Croger.kratz%40teleopti.com%7C6686e8253ac94f00033a08d59be6eafb%7C449a67e94f234e758bccf32dd77cefe0%7C0%7C1%7C636586338476016018&sdata=%2F4prEKBbE7fW7MXJ1m9eMGf%2Bu4Nd36FaTwgzdvYc21c%3D&reserved=0>.

--
You received this message because you are subscribed to a topic in the Google Groups "nhusers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/nhusers/39RnNkXgz78/unsubscribe<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Ftopic%2Fnhusers%2F39RnNkXgz78%2Funsubscribe&data=02%7C01%7Croger.kratz%40teleopti.com%7C6686e8253ac94f00033a08d59be6eafb%7C449a67e94f234e758bccf32dd77cefe0%7C0%7C1%7C636586338476016018&sdata=%2BbJdK3SlVRIZhVRqWoFl%2FvBcwep%2FB8maw2uLkyON9sQ%3D&reserved=0>.
To unsubscribe from this group and all its topics, send an email to nhusers+***@googlegroups.com<mailto:nhusers+***@googlegroups.com>.
To post to this group, send email to ***@googlegroups.com<mailto:***@googlegroups.com>.
Visit this group at https://groups.google.com/group/nhusers<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fgroup%2Fnhusers&data=02%7C01%7Croger.kratz%40teleopti.com%7C6686e8253ac94f00033a08d59be6eafb%7C449a67e94f234e758bccf32dd77cefe0%7C0%7C1%7C636586338476016018&sdata=euT%2BbmiMmXBkYG0Q8PqbKmxQ0sEItM40sVHgBSk%2FUY4%3D&reserved=0>.
For more options, visit https://groups.google.com/d/optout<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Foptout&data=02%7C01%7Croger.kratz%40teleopti.com%7C6686e8253ac94f00033a08d59be6eafb%7C449a67e94f234e758bccf32dd77cefe0%7C0%7C1%7C636586338476016018&sdata=%2F4prEKBbE7fW7MXJ1m9eMGf%2Bu4Nd36FaTwgzdvYc21c%3D&reserved=0>.


--
You received this message because you are subscribed to the Google Groups "nhusers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nhusers+***@googlegroups.com<mailto:nhusers+***@googlegroups.com>.
To post to this group, send email to ***@googlegroups.com<mailto:***@googlegroups.com>.
Visit this group at https://groups.google.com/group/nhusers<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fgroup%2Fnhusers&data=02%7C01%7Croger.kratz%40teleopti.com%7C6686e8253ac94f00033a08d59be6eafb%7C449a67e94f234e758bccf32dd77cefe0%7C0%7C1%7C636586338476016018&sdata=euT%2BbmiMmXBkYG0Q8PqbKmxQ0sEItM40sVHgBSk%2FUY4%3D&reserved=0>.
For more options, visit https://groups.google.com/d/optout<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fd%2Foptout&data=02%7C01%7Croger.kratz%40teleopti.com%7C6686e8253ac94f00033a08d59be6eafb%7C449a67e94f234e758bccf32dd77cefe0%7C0%7C1%7C636586338476016018&sdata=%2F4prEKBbE7fW7MXJ1m9eMGf%2Bu4Nd36FaTwgzdvYc21c%3D&reserved=0>.