I have always been skeptical of rewriting working code - porting code is no exception to this. However, with the advent of TDD and automated testing it is much more reasonable to rewrite and refactor code.

Does anyone know if there is a TDD tool that can be used for porting old code? Ideally you could do the following:

  1. Write up language agnostic unit tests for the old code that pass (or fail if you find bugs!).
  2. Run unit tests on your other code base that fail.
  3. Write code in your new language that passes the tests without looking at the old code.

The alternative would be to split step 1 into "Write up unit tests in language 1" and "Port unit tests to language 2", which significantly increases effort required and is difficult to justify if the old code base is going to stop being maintained after the port (that is, you don't get the benefit of continuous integration on this code base).

EDIT: It's worth noting this question on StackOverflow.

  • Provide a pure text command protocol, and then use expect to implement your tests.
    – SK-logic
    Nov 18, 2011 at 7:31
  • @SK-logic I hadn't heard of expect. If you have a Unix-style legacy system that communicates with pipes using stdin and stdout then that tool can be used for sure. In fact, it would be quite easy to test with any scripting language too.
    – Bringer128
    Nov 18, 2011 at 7:38
  • why legacy? You can have a unix-style modern system as well. Anyway, there never exist a valid justification for not providing a scripting interface to any piece of functionality.
    – SK-logic
    Nov 18, 2011 at 9:10
  • @SK-logic Sorry for not being clear. I said "legacy" because porting is generally done from legacy language x to fancy new language y. I wasn't attempting to imply anything about Unix!
    – Bringer128
    Nov 18, 2011 at 9:13
  • @Bringer123, by the way, my little trick for doing this sort of a unix-like integration without any decent Unix support (e.g., no proper pipes) is to embed a scripting language and provide an access to its REPL via TCP port (with REPL running in a separate thread). It is both a powerful debugging tool and tests automation engine. And this approach works with literally everything (an embedded scripting language can be really tiny, it can even be a Forth in a limited resources scenario).
    – SK-logic
    Nov 18, 2011 at 9:48

5 Answers 5


I don't think it's possible to write unit tests in a different language.

However, what you can do is write integration/acceptance/user interface / whaterver_you_name_it tests that would be very high level and would not be tied to the language your software is written with.

If your application is a webservice, you can test it with whatever language you want, providing it supports your protocol. If your application runs in a browser, you can use selenium (that's the first that came to my mind, but there are others. Etc. There might be some cases where it would not work I imagine (maybe hardware stuff), it all depends on the type of application you are working on.

Of course, you won't have the same coverage as you would have with unit level tests (unless spending a lot of time), but at least, you would have a test harness.

  • +1 for the automated high level tests. These would definitely be worth the effort to produce.
    – Bringer128
    Nov 18, 2011 at 9:05
  • 1
    "I don't think it's possible to write unit tests in a different language.": counter example: in .NET, you can write unit tests of C# in Visual Basic (or any other .NET-enabled language). A few years ago, this was even promoted by Microsoft as a best practice, since it lowers the risk of making in both code and tests the same mistake related to the language (and specifically programmer's relative misunderstanding of it). Agreed, one won't write unit tests in Fortran to test PHP code. Oct 13, 2014 at 13:24

I think what comes closest to your idea is unit test frameworks on virtual machine based ecosystems such as the Java VM. At least Scala (and I believe Groovy too - I am not quite sure about Clojure) is almost perfectly interoperable with Java. That is, Scala code can be tested with JUnit and Java code can be tested with ScalaTest. This way you can (gradually or at once) rewrite Java code in Scala and keep using the same old Java unit tests to verify its correctness. (Or the other way around - although I can't imagine a valid reason to migrate from Scala back to Java.)

Probably the same is true to languages on the .NET CLI, e.g. C#, F#, ASP.NET et al.

Outside of a VM/CLR, however, it is more difficult. In theory, one could compile unit tests and/or code under test into another language such as C (as was and is common with new languages such as early C++ etc.), but I haven't heard of anyone trying this out specifically with unit tests.

  • 1
    I guess this shows the problem with my question. If they can interoperate easily, why port? And if they can't, then the language barrier makes it impossible to do cross-language unit tests.
    – Bringer128
    Nov 18, 2011 at 9:03
  • @Bringer128, proponents of the new breed of JVM languages claim that specific problems can be solved faster, with significantly less and cleaner code than in Java. My limited experience with Scala confirms this so far. Nov 18, 2011 at 9:25
  • Groovy interoperates with Java just as well.
    – user281377
    Oct 13, 2014 at 13:31

Such framework doesn't exists, because it needs to be written in the language of the code that is used.

For example, a framework for testing c++ code needs to be written in c or c++. Using framework written in c++ might, but it is not going to test a c code if it uses c++ features.


Methodologies vary, but in my case a big part of my TDD tests tend to the 'integration test' style, as opposed from 'unit test'. That is, most of my them test the whole program in nearly-real-life queries, checking for appropriate responses.

In a few cases, when I wrote network driven programs (mostly application-specific protocols), I didn't have a full test framework handy that felt easy for the job, so I did most of the testing 'across the network', in short, I wrote a very simple client in another language with a common and simple test framework, and most of the tests checked the server's responses.

Still, even in those cases, I injected a few hand-rolled tests in the real application to test some non-network parts.


Language agnostic test framework are generic test framework suited for acceptance test (point of view) and testcases in that framework is managed by QA e.g Robotframework

  • 2
    this doesn't seem to offer anything substantial over points made and explained in prior 4 answers
    – gnat
    Oct 13, 2014 at 13:08

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