Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Relating to this question, I have another question regarding unit testing functions in the utility classes:

Assume you have function signatures like this:

public function void doSomething(InternalClass obj, InternalElement element)

where InternalClass and InternalElement are both Classes which source code are not available, because they are hidden in the API. Additionally, doSomething only operates on obj and element. I thought about mocking those classes away but this option is not possible due to the fact that they do not implement an interface at all which I could use for my Mocking classes.

However, I need to fill obj with defined data to test doSomething.

How can this problem be solved?

share|improve this question
    
Thinking out loud a bit here, but would this be a good use case for PEX? (research.microsoft.com/en-us/projects/pex) –  James Snell Jun 18 '13 at 10:27
1  
How about the obvious: in the preparation of your test, you create an InternalClass and InternalElement instance and manipulate those (through their interfaces) into the right state for your test. –  Bart van Ingen Schenau Jun 18 '13 at 10:29
    
@JamesSnell: I tried PEX some months ago and found it very disillusioning. It's a nice research project, but I don't think it really helps to to test the important things. And it does not solve the OP's problem. –  Doc Brown Jun 18 '13 at 10:39
    
I think James means Moles, not Pex (pex is more of a test generator). Often used together. –  Joppe Jun 19 '13 at 0:00
add comment

4 Answers

up vote 3 down vote accepted

What you are looking for is the adapter pattern: http://www.dofactory.com/Patterns/PatternAdapter.aspx

Using this pattern you can create a wrapper around the external class.

Lets take the following external class:

public sealed class SomeExternalClassWithoutInterface
{
    private readonly string _someValue;

    public SomeExternalClassWithoutInterface(string someConstructorValue)
    {
        _someValue = someConstructorValue;
    }
    public string Method1()
    {
        return _someValue;
    }

    public int Method2()
    {
        return _someValue.Length;
    }
}

We can now easily create our own class as a wrapper around this external class, and Implement an interface:

public class ExternalClassAdapter : IExternalClassAdapter
{
private readonly SomeExternalClassWithoutInterface _someExternalClassWithoutInterface;

// DI implementation, this is not neccesary
public ExternalClassAdapter(SomeExternalClassWithoutInterface someExternalClassWithoutInterface)
{
    _someExternalClassWithoutInterface = someExternalClassWithoutInterface;
}

// Constructor Without Depedency Injection, this is not preferable.
public ExternalClassAdapter(string someValue)
{
   _someExternalClassWithoutInterface = new SomeExternalClassWithoutInterface(someValue);
}

public string Method1()
{
    return _someExternalClassWithoutInterface.Method1();
}

public int Method2()
{
    return _someExternalClassWithoutInterface.Method2();
}

}

This is our interface, which is implementing all the methods used in the external class. (If alot of methods are available, seperate the interfaces according to the Interface Segregation principle)

public interface IExternalClassAdapter
    {
        string Method1();
        int Method2();
    }

Now, when this Adapter class is used in your application instead of the external class, you should be able to mock any other implementation pretty easy.

You should never use non interfaced external classes in your code.

Pastebin link (since the code outlining is not working well here): http://pastebin.com/2qN7u3u6

If, for any reason, you also need a facade pattern... You can still wrap these 2 adapters in a single facade! But do not create a single facade on 2 external classes!

share|improve this answer
add comment

If it's not too late to change some of your own code you could wrap the InternalClass and InternalElement and provide an interface for the wrapper so that the wrapped object can be easily mocked (essentially the adapter pattern).

If you don't control these classes it's probably a good idea to wrap them anyway to isolate changes in them from your code.

share|improve this answer
    
You're explenation looks OK, but aren't you refering to the adapter pattern? (look at my answer). I'm not 100% sure that my example is using only the Adapter pattern, but i'm adapting the external class to implement my own interface so that it fits in my application... => adapter pattern? Facade pattern is just a wrapper around multiple objectsn to simplify certain actions: en.wikipedia.org/wiki/Facade_pattern (take a look at the computer example, where computer.Start is a simplified interface to start all of the different components) –  Frederik P. Jun 25 '13 at 7:31
    
it could be both, note he has two components to wrap, so a facade for both would be appropriate I think. The important part is you expose an interface for the wrapper –  jk. Jun 25 '13 at 7:53
    
Depends, facade pattern should not be used to wrap 2 (non-interfaced) objects to expose an interface (which helps u in testing). Facade pattern with 2 objects is used to expose a simplified interface for related objects: read as: A single method call (computer.start) which will call appropriate methods of the 2 external objects (i.e. memory.start, cpu.start). This is usefull since memory and CPU should not be started seperatly. In this case, since it might be usefull to make BOTH objects mockable, you will need to create 2 adapter's instead of one facade... –  Frederik P. Jun 25 '13 at 8:05
    
If you still want a single, simplified interface for both objects, you can still use the facade pattern. But this has to happen after you have created 2 adapter's. So you'r facade should NOT use the external objects, but your own addapter implementation. The reason is: we want to avoid external classes in our application... So the first step when working with external objects is creating your own adapter! Now, you are free to do whatever you want with those adapters... –  Frederik P. Jun 25 '13 at 8:08
    
ok you've convinced me it's adapter –  jk. Jun 25 '13 at 12:58
show 1 more comment

You probably already tried this option, but you don't specifically state so in your question:

Can you instantiate the objects and set them to a certain state? Perhaps calling doSomething results in a some new state that is enough to verify it has properly operated on the objects?

Of course if one of the objects launches a nuclear missile touches a lot of external state it may be a no-no.

share|improve this answer
add comment

Here is a trick that sometimes works in cases like that: in your testing assembly, do not reference the assembly containing doSomething. Instead, reference the source code file containg doSomething, and provide your own InternalClass / InternalElement implementation (which serves as a mock) in that testing assembly . Of course, your InternalClass must expose exactly the same public method signatures as the original one, at least to the degree that you can compile the test code. It should be obvious that you also have to use the same namespace as the original class.

I have used this technique sucessfully for testing legacy code even though I had the source code available, but did not want to touch it.

share|improve this answer
    
Strange answer, knowing he mentioned not having the source code available. But imagine he had the source code available, if the external object inherits a public interface, there is no problem. You can just mock anything that inherits a public interface... So I do not understand your answer 100%... –  Frederik P. Jun 26 '13 at 12:44
    
@FrederikP.: he has the source code available - of doSomething (not of the original InternalClass / InternalElement), of course. My suggestion avoids the need for creating a wrapper and the need for changing anyting in doSomething to get this under test. –  Doc Brown Jun 27 '13 at 21:01
    
First of all, you are stating his "fake InternalClass" should inherit the same public interface as the original one... But as the OP mentioned, InternalClass does n ot inherit an interface. Since it's abad practise (when focussing on testability) to work with objects which do not inherit any useful interface I always advice people to create your own wrapper (adapter). This way you are also keeping your application infrastructure clean from "thirth party code". Could you show any code sample? Since I try to read your answer over and over again but fail to understand how this solves his issue. –  Frederik P. Jun 28 '13 at 7:36
    
@FrederikP.: perhaps my edit makes it clearer, I did not mean "public interface" in the sense of the C# language element "interface", but in the sense of "public method signatures". –  Doc Brown Jun 28 '13 at 11:16
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.