xUnit to replace thirdParty class instance with a fake one
up vote
2
down vote
favorite
Part of my class initialize an object to an MLM ( which required a lot of setups and installations) what I need is to replace it
with a fake object to Do the same in an easy way,
For example how to test the following code with a fake object
// LMXProxyServerClass is the library in which need a lot of installation
private readonly LMXProxyServerClass lmxProxyServer;
And this is an example of one of the methods I use in
private bool CreateBindingWithoutPropagate(string attributeName, bool supervisory)
{
bool creatingBindingResult = false;
lock (mxAccessProxyLock)
{
if (!bindings.ContainsKey(attributeName))
{
try
{
logger.Debug("Adding item " + attributeName + " to bindings, not in list so add.");
// Add the handle to the mapping
lmxHandleToAttributeNameMapping.Add(attributeBinding.MxAttributeHandle, attributeName);
if (supervisory)
{
lmxProxyServer.DoSOmethingElse(yyyyyyyyyyyyyyyyyyyyyyy);
logger.Info(xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx);
}
else
{
lmxProxyServer.DoSOmething(xxxxxxxx);
logger.Info(xxxxxxxxxxx);
}
// Add the binding to the list of bindings.
bindings.Add(attributeName, attributeBinding);
logger.Info("Creating binding for: " + attributeName);
creatingBindingResult = true;
}
catch (System.UnauthorizedAccessException unauthorizedAccessException)
{
logger.Error("xxxxxxxxxxx", attributeName);
throw ConvertExceptionToFault(unauthorizedAccessException);
}
catch (Exception ex)
{
throw ConvertExceptionToFault(ex);
}
}
}
return creatingBindingResult;
}
This library is third-party one so I have no control over it, so in testing I need to replace this object with fake one so I don't change a lot in the base code and ease the testing of other parts
c# unit-testing xunit.net
add a comment |
up vote
2
down vote
favorite
Part of my class initialize an object to an MLM ( which required a lot of setups and installations) what I need is to replace it
with a fake object to Do the same in an easy way,
For example how to test the following code with a fake object
// LMXProxyServerClass is the library in which need a lot of installation
private readonly LMXProxyServerClass lmxProxyServer;
And this is an example of one of the methods I use in
private bool CreateBindingWithoutPropagate(string attributeName, bool supervisory)
{
bool creatingBindingResult = false;
lock (mxAccessProxyLock)
{
if (!bindings.ContainsKey(attributeName))
{
try
{
logger.Debug("Adding item " + attributeName + " to bindings, not in list so add.");
// Add the handle to the mapping
lmxHandleToAttributeNameMapping.Add(attributeBinding.MxAttributeHandle, attributeName);
if (supervisory)
{
lmxProxyServer.DoSOmethingElse(yyyyyyyyyyyyyyyyyyyyyyy);
logger.Info(xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx);
}
else
{
lmxProxyServer.DoSOmething(xxxxxxxx);
logger.Info(xxxxxxxxxxx);
}
// Add the binding to the list of bindings.
bindings.Add(attributeName, attributeBinding);
logger.Info("Creating binding for: " + attributeName);
creatingBindingResult = true;
}
catch (System.UnauthorizedAccessException unauthorizedAccessException)
{
logger.Error("xxxxxxxxxxx", attributeName);
throw ConvertExceptionToFault(unauthorizedAccessException);
}
catch (Exception ex)
{
throw ConvertExceptionToFault(ex);
}
}
}
return creatingBindingResult;
}
This library is third-party one so I have no control over it, so in testing I need to replace this object with fake one so I don't change a lot in the base code and ease the testing of other parts
c# unit-testing xunit.net
add a comment |
up vote
2
down vote
favorite
up vote
2
down vote
favorite
Part of my class initialize an object to an MLM ( which required a lot of setups and installations) what I need is to replace it
with a fake object to Do the same in an easy way,
For example how to test the following code with a fake object
// LMXProxyServerClass is the library in which need a lot of installation
private readonly LMXProxyServerClass lmxProxyServer;
And this is an example of one of the methods I use in
private bool CreateBindingWithoutPropagate(string attributeName, bool supervisory)
{
bool creatingBindingResult = false;
lock (mxAccessProxyLock)
{
if (!bindings.ContainsKey(attributeName))
{
try
{
logger.Debug("Adding item " + attributeName + " to bindings, not in list so add.");
// Add the handle to the mapping
lmxHandleToAttributeNameMapping.Add(attributeBinding.MxAttributeHandle, attributeName);
if (supervisory)
{
lmxProxyServer.DoSOmethingElse(yyyyyyyyyyyyyyyyyyyyyyy);
logger.Info(xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx);
}
else
{
lmxProxyServer.DoSOmething(xxxxxxxx);
logger.Info(xxxxxxxxxxx);
}
// Add the binding to the list of bindings.
bindings.Add(attributeName, attributeBinding);
logger.Info("Creating binding for: " + attributeName);
creatingBindingResult = true;
}
catch (System.UnauthorizedAccessException unauthorizedAccessException)
{
logger.Error("xxxxxxxxxxx", attributeName);
throw ConvertExceptionToFault(unauthorizedAccessException);
}
catch (Exception ex)
{
throw ConvertExceptionToFault(ex);
}
}
}
return creatingBindingResult;
}
This library is third-party one so I have no control over it, so in testing I need to replace this object with fake one so I don't change a lot in the base code and ease the testing of other parts
c# unit-testing xunit.net
Part of my class initialize an object to an MLM ( which required a lot of setups and installations) what I need is to replace it
with a fake object to Do the same in an easy way,
For example how to test the following code with a fake object
// LMXProxyServerClass is the library in which need a lot of installation
private readonly LMXProxyServerClass lmxProxyServer;
And this is an example of one of the methods I use in
private bool CreateBindingWithoutPropagate(string attributeName, bool supervisory)
{
bool creatingBindingResult = false;
lock (mxAccessProxyLock)
{
if (!bindings.ContainsKey(attributeName))
{
try
{
logger.Debug("Adding item " + attributeName + " to bindings, not in list so add.");
// Add the handle to the mapping
lmxHandleToAttributeNameMapping.Add(attributeBinding.MxAttributeHandle, attributeName);
if (supervisory)
{
lmxProxyServer.DoSOmethingElse(yyyyyyyyyyyyyyyyyyyyyyy);
logger.Info(xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx);
}
else
{
lmxProxyServer.DoSOmething(xxxxxxxx);
logger.Info(xxxxxxxxxxx);
}
// Add the binding to the list of bindings.
bindings.Add(attributeName, attributeBinding);
logger.Info("Creating binding for: " + attributeName);
creatingBindingResult = true;
}
catch (System.UnauthorizedAccessException unauthorizedAccessException)
{
logger.Error("xxxxxxxxxxx", attributeName);
throw ConvertExceptionToFault(unauthorizedAccessException);
}
catch (Exception ex)
{
throw ConvertExceptionToFault(ex);
}
}
}
return creatingBindingResult;
}
This library is third-party one so I have no control over it, so in testing I need to replace this object with fake one so I don't change a lot in the base code and ease the testing of other parts
c# unit-testing xunit.net
c# unit-testing xunit.net
edited Nov 21 at 15:53
Mark Seemann
181k33322554
181k33322554
asked Nov 21 at 9:21
Ali
90452345
90452345
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
up vote
2
down vote
accepted
Tightly coupling code to 3rd party implementation concerns make it difficult to unit test the code in isolation.
Instead encapsulate 3rd party implementation concern in an abstraction that can be mocked as needed when testing.
For example, create an abstraction of the 3rd party dependency, exposing only what is needed by your code.
public interface ILMXProxyServer {
void DoSOmethingElse(...);
void DoSOmething(...);
//...
}
and have that explicitly injected into dependents via constructor injection.
public class MyClass {
private readonly ILMXProxyServer lmxProxyServer;
public MyClass(ILMXProxyServer lmxProxyServer) {
this.lmxProxyServer = lmxProxyServer;
}
//...other code omitted for brevity
}
The methods remain the same as they will call exposed members of the abstraction.
The run time implementation will wrap/encapsulate the 3rd party dependency
public class MyLMXProxyServerWrapper : ILMXProxyServer {
// LMXProxyServerClass is the library in which need a lot of installation
private readonly LMXProxyServerClass lmxProxyServer;
public void DoSOmething(Something xxxxxxx){
lmxProxyServer.DoSOmething(xxxxxxxx);
}
//...code omitted for brevity
}
With that refactor the code is now more flexible to be able to mock/fake the proxy server when testing in isolation using your mocking framework of choice or by rolling your own implementations specific for testing.
it's a brilliant idea, what am thinking bout how to implement this and passing the value as I use topshelf to host this wcf service
– Ali
Nov 21 at 11:44
@Ali Research Dependency Inversion. If unable to use an IoC container then Pure DI can still work wonders.
– Nkosi
Nov 21 at 12:38
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
Tightly coupling code to 3rd party implementation concerns make it difficult to unit test the code in isolation.
Instead encapsulate 3rd party implementation concern in an abstraction that can be mocked as needed when testing.
For example, create an abstraction of the 3rd party dependency, exposing only what is needed by your code.
public interface ILMXProxyServer {
void DoSOmethingElse(...);
void DoSOmething(...);
//...
}
and have that explicitly injected into dependents via constructor injection.
public class MyClass {
private readonly ILMXProxyServer lmxProxyServer;
public MyClass(ILMXProxyServer lmxProxyServer) {
this.lmxProxyServer = lmxProxyServer;
}
//...other code omitted for brevity
}
The methods remain the same as they will call exposed members of the abstraction.
The run time implementation will wrap/encapsulate the 3rd party dependency
public class MyLMXProxyServerWrapper : ILMXProxyServer {
// LMXProxyServerClass is the library in which need a lot of installation
private readonly LMXProxyServerClass lmxProxyServer;
public void DoSOmething(Something xxxxxxx){
lmxProxyServer.DoSOmething(xxxxxxxx);
}
//...code omitted for brevity
}
With that refactor the code is now more flexible to be able to mock/fake the proxy server when testing in isolation using your mocking framework of choice or by rolling your own implementations specific for testing.
it's a brilliant idea, what am thinking bout how to implement this and passing the value as I use topshelf to host this wcf service
– Ali
Nov 21 at 11:44
@Ali Research Dependency Inversion. If unable to use an IoC container then Pure DI can still work wonders.
– Nkosi
Nov 21 at 12:38
add a comment |
up vote
2
down vote
accepted
Tightly coupling code to 3rd party implementation concerns make it difficult to unit test the code in isolation.
Instead encapsulate 3rd party implementation concern in an abstraction that can be mocked as needed when testing.
For example, create an abstraction of the 3rd party dependency, exposing only what is needed by your code.
public interface ILMXProxyServer {
void DoSOmethingElse(...);
void DoSOmething(...);
//...
}
and have that explicitly injected into dependents via constructor injection.
public class MyClass {
private readonly ILMXProxyServer lmxProxyServer;
public MyClass(ILMXProxyServer lmxProxyServer) {
this.lmxProxyServer = lmxProxyServer;
}
//...other code omitted for brevity
}
The methods remain the same as they will call exposed members of the abstraction.
The run time implementation will wrap/encapsulate the 3rd party dependency
public class MyLMXProxyServerWrapper : ILMXProxyServer {
// LMXProxyServerClass is the library in which need a lot of installation
private readonly LMXProxyServerClass lmxProxyServer;
public void DoSOmething(Something xxxxxxx){
lmxProxyServer.DoSOmething(xxxxxxxx);
}
//...code omitted for brevity
}
With that refactor the code is now more flexible to be able to mock/fake the proxy server when testing in isolation using your mocking framework of choice or by rolling your own implementations specific for testing.
it's a brilliant idea, what am thinking bout how to implement this and passing the value as I use topshelf to host this wcf service
– Ali
Nov 21 at 11:44
@Ali Research Dependency Inversion. If unable to use an IoC container then Pure DI can still work wonders.
– Nkosi
Nov 21 at 12:38
add a comment |
up vote
2
down vote
accepted
up vote
2
down vote
accepted
Tightly coupling code to 3rd party implementation concerns make it difficult to unit test the code in isolation.
Instead encapsulate 3rd party implementation concern in an abstraction that can be mocked as needed when testing.
For example, create an abstraction of the 3rd party dependency, exposing only what is needed by your code.
public interface ILMXProxyServer {
void DoSOmethingElse(...);
void DoSOmething(...);
//...
}
and have that explicitly injected into dependents via constructor injection.
public class MyClass {
private readonly ILMXProxyServer lmxProxyServer;
public MyClass(ILMXProxyServer lmxProxyServer) {
this.lmxProxyServer = lmxProxyServer;
}
//...other code omitted for brevity
}
The methods remain the same as they will call exposed members of the abstraction.
The run time implementation will wrap/encapsulate the 3rd party dependency
public class MyLMXProxyServerWrapper : ILMXProxyServer {
// LMXProxyServerClass is the library in which need a lot of installation
private readonly LMXProxyServerClass lmxProxyServer;
public void DoSOmething(Something xxxxxxx){
lmxProxyServer.DoSOmething(xxxxxxxx);
}
//...code omitted for brevity
}
With that refactor the code is now more flexible to be able to mock/fake the proxy server when testing in isolation using your mocking framework of choice or by rolling your own implementations specific for testing.
Tightly coupling code to 3rd party implementation concerns make it difficult to unit test the code in isolation.
Instead encapsulate 3rd party implementation concern in an abstraction that can be mocked as needed when testing.
For example, create an abstraction of the 3rd party dependency, exposing only what is needed by your code.
public interface ILMXProxyServer {
void DoSOmethingElse(...);
void DoSOmething(...);
//...
}
and have that explicitly injected into dependents via constructor injection.
public class MyClass {
private readonly ILMXProxyServer lmxProxyServer;
public MyClass(ILMXProxyServer lmxProxyServer) {
this.lmxProxyServer = lmxProxyServer;
}
//...other code omitted for brevity
}
The methods remain the same as they will call exposed members of the abstraction.
The run time implementation will wrap/encapsulate the 3rd party dependency
public class MyLMXProxyServerWrapper : ILMXProxyServer {
// LMXProxyServerClass is the library in which need a lot of installation
private readonly LMXProxyServerClass lmxProxyServer;
public void DoSOmething(Something xxxxxxx){
lmxProxyServer.DoSOmething(xxxxxxxx);
}
//...code omitted for brevity
}
With that refactor the code is now more flexible to be able to mock/fake the proxy server when testing in isolation using your mocking framework of choice or by rolling your own implementations specific for testing.
edited Nov 21 at 16:05
answered Nov 21 at 9:50
Nkosi
105k15111180
105k15111180
it's a brilliant idea, what am thinking bout how to implement this and passing the value as I use topshelf to host this wcf service
– Ali
Nov 21 at 11:44
@Ali Research Dependency Inversion. If unable to use an IoC container then Pure DI can still work wonders.
– Nkosi
Nov 21 at 12:38
add a comment |
it's a brilliant idea, what am thinking bout how to implement this and passing the value as I use topshelf to host this wcf service
– Ali
Nov 21 at 11:44
@Ali Research Dependency Inversion. If unable to use an IoC container then Pure DI can still work wonders.
– Nkosi
Nov 21 at 12:38
it's a brilliant idea, what am thinking bout how to implement this and passing the value as I use topshelf to host this wcf service
– Ali
Nov 21 at 11:44
it's a brilliant idea, what am thinking bout how to implement this and passing the value as I use topshelf to host this wcf service
– Ali
Nov 21 at 11:44
@Ali Research Dependency Inversion. If unable to use an IoC container then Pure DI can still work wonders.
– Nkosi
Nov 21 at 12:38
@Ali Research Dependency Inversion. If unable to use an IoC container then Pure DI can still work wonders.
– Nkosi
Nov 21 at 12:38
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53408772%2fxunit-to-replace-thirdparty-class-instance-with-a-fake-one%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown