Is it acceptable practice to unit-test a program in a different language?

Question

I have a static library I created from C++, and would like to test this using a Driver code.

I noticed one of my professors like to do his tests using python, but he simply executes the program (not a library in this case, but an executable) using random test arguments.

I would like to take this approach, but I realized that this is a library and doesn't have a main function; that would mean I should either create a Driver.cpp class, or wrap the library into python using SWIG or boost python.

I’m planning to do the latter because it seems more fun, but logically, I feel that there is going to be more bugs when trying to wrap a library to a different language just to test it, rather than test it in its native language.

Is testing programs in a different language an accepted practice in the real world, or is this bad practice?

Answer 1

I'd say that it's best to test the API that your users will be exposed to. Other tests are good to have as well, but that's the most important aspect.

If your users are going to write C/C++ code linking to your library, then it would be good to have tests making use of your library the same way.

If you are going to ship a Python wrapper (why not?) then you should have Python tests.

Of course, there is a convenience aspect to this, as well. It may be easier to write tests in Python, and you might have time constraints that make it more appealing, etc.

I guess what I'm saying is: There's nothing inherently wrong with tests being in a different language from the code under test (that's totally normal for testing a REST API, for instance), but make sure you have tests for the public-facing API at a minimum.

---

Aside, on terminology:

I don't think the types of tests you are describing are "unit tests" in the usual sense of the term. Probably "functional test" would be more accurate.

A unit test typically tests a very small component - such as a function call - that might be one piece of larger functionality. Unit tests like these are often "white box" tests, so you can see the inner workings of your code.

Testing something from a user's point-of-view (such as your professor's commandline tests) are "black box" tests, and in these examples are at a more functional level rather than "unit" level.

I'm sure plenty of people may disagree with that, though - it's not a rigidly-defined set of terms.

Answer 2

A few things to keep in mind:

1. If you are writing tests as you code, then, by all means, use whatever language works best to give you rapid feedback. This enables fast test-code cycles (and is fun as well). BUT.

2. Always have well-written tests in the language of the consumer. How is your client/consumer going to call your functions? What language will they be using? Using the same language minimizes integration issues later on in the life-cycle.