Unit-testing functions with user-defined types

How can we build unit-tests for functions of libraries, those with user-defined types used as their arguments ?

For example

CRecord func(Myclass * class, BSTR * name, CComptr<xxx> & something);

Thanks a lot.

The main principle is mocking types the tested function depends on.

With this you may find unit testing almost impossible for a tightly coupled code. :)

Thank you, the only weird thing is I could not find any tutorials or example code to do what you suggested me. Are there any underlying claims for *never* mocking user-defined, COM related functions ? Because if this is a must-do thing in unit tests, there should be questions or source code I could google out.

Would you mind providing me a wrapper class you have dealt with to unit-test any COM functions or those with COM related arguments ?

I can only do simple things like this

for a function

Code:

---

int foo(int i, char c){...;return 1;}

---

then my test method is

Code:

---

TEST_METHOD(foo)
{
      MyCls cls;
      Assert::AreEqual(1,cls.foo(1,'1'));
}

---

I don't get what you talk about. You test only what you test, you mock everything else. The framework you use ideally helps you to generate mocked interfaces. If it does not, you either find another testing framework or re-design your tested code to comply with the framework.

Not any code can be unit-tested, especially C++ code that is usually prone to tight coupling.

As for the COM thing, again, I don't get your point. The tested code must be isolated from OS stuff, databases, hardware, etc. This is what mocking is about first of all. Otherwise, your testing stops being unit testing, and becomes integration testing instead.

Quote:

---

Originally Posted by Igor Vartanov

I don't get what you talk about. You test only what you test, you mock everything else. The framework you use ideally helps you to generate mocked interfaces. If it does not, you either find another testing framework or re-design your tested code to comply with the framework.

Not any code can be unit-tested, especially C++ code that is usually prone to tight coupling.

As for the COM thing, again, I don't get your point. The tested code must be isolated from OS stuff, databases, hardware, etc. This is what mocking is about first of all. Otherwise, your testing stops being unit testing, and becomes integration testing instead.

---

Thank you, for example, now I hand you in the Boost library and I would like you to write all unit-tests for the library's functions/methods in all classes using MSVS2012, what are you going to do then ? How do you know what functions are testable or not, given that you have never used Boost before.

Quote:

---

Originally Posted by terminalXXX

Thank you, for example, now I hand you in the Boost library and I would like you to write all unit-tests

---

Why? The library's authors are responsible for unit testing their code, not the end-user of the library. It is expected that the library works correctly with your application, no different than the C++ runtime and standard libraries.

If you're using a third-party library correctly and properly and you then see something wrong, then you write a test case to confirm a bug and contact the author(s) as to what you found.

Regards,

Paul McKenzie

Thank you Paul. It was just an example of the situation I am in right now.

The requirement we have right now is to upgrade the current library (previous team wrote it). Previous authors didn't include unit-tests in each of the methods they wrote to export as those of Dll's. I am very confused about mock, fake, stub etc because I don't know how to mock a CComPtr type argument that is used in many places in functions in the dlls.
Could you provide me an simple example of mock a CComPtr (COM pointer type) and type that is user-defined, the more complex, the better ? Thank you.

Man, it seems you don't listen. Not any code can be unit tested. If you can't mock the type you have to mock, you either change your code or switch to a smarter unit test framework.

In your situation it would be really stupid to mock such complex types like boost or comdef types, as the effort hardly worth the result. So you have to either redesign your interfaces or give up.

Once again, not any code can be unit tested. Unit testing is just a requirement that can or cannot be met. If you have to unit-test, your code has to be designed appropriately.

Quote:

---

Originally Posted by Igor Vartanov

Man, it seems you don't listen. Not any code can be unit tested. If you can't mock the type you have to mock, you either change your code or switch to a smarter unit test framework.

In your situation it would be really stupid to mock such complex types like boost or comdef types, as the effort hardly worth the result. So you have to either redesign your interfaces or give up.

Once again, not any code can be unit tested. Unit testing is just a requirement that can or cannot be met. If you have to unit-test, your code has to be designed appropriately.

---

No, I am listening, but I do need more information to have a good and correct argument for debates of what I should follow. All code in my library is not really hard, only the user-defined types used as arguments that are spead thru-out the dlls and unit-tests I need to write are messy and overwhelming.

Quote:

---

Originally Posted by terminalXXX

and unit-tests I need to write are messy and overwhelming.

---

This is what I told you about, exactly it is: you have to redesign your call interfaces until unit testing becomes easy going and natural.