I need to write two versions of the same application, one in .NET and the other one in Java. So I'd like to write a single test suite, and then use it against both codebases.
Which testing tool would you advise me to use?
+3
A:
I see two strategies:
Wrap the code to test in some kind of server, so you can invoke the methods to test remotely. This would allow you to use any test suite.
Write the tests in something like J# or any other language which you can easily map to .NET and Java. This means you write the tests once and then "translate" the test code into something two different testing frameworks can understand.
I suggest to try the second approach first. It will make tests much faster at the price of a more complex test setup. The first approach is probably more simple to set up but it will make the tests slower and you'll need to start and tear down the server somewhere in the tests.
Aaron Digulla
2009-09-25 07:43:25
We are mainly a .NET shop, so it would be easy for us if we could write the tests in a CLR language. However, I don't want to mess with the test code. Ideally, I would just write the test once. Thanks.
santiiiii
2009-09-25 08:12:10
Running a script that translates the code from one language to another (when those two languages are very similar) isn't "messing" :)
Aaron Digulla
2009-09-25 08:19:09
I guess that's doable, but, once again, I'd rather make do without having to write more support code. I'll consider it nonetheless.
santiiiii
2009-09-25 08:38:42
+6
A:
Interesting question..
I think, that you can to use xUnit implementations for Java (JUnit, most likely) and .NET. But your test code must be written it some third language, probably simple DSL for testing that you can design by yourself. This language is to be translated to Java and C# source files.
Other option is not to mess with own language and take some existing one. E.g. Python has implementations for both platforms: Jython (Java) and IronPython (.NET). So you can write tests in that language. Python has its own bundled xUnit implementation: unittest package.
Rorick
2009-09-25 07:48:02
Designing my own DSL sounds too complicated, but I think the python approach is worth considering.Thanks
santiiiii
2009-09-25 08:07:09
+2
A:
I am just not sure why you would want to to have parallel implementations in Java and .NET and go thorugh the redundancy of maintaining 2 codebases. Python does provide a scriptable test harness but will have ceveats in each platform i.e. not all core python modules have been ported to java AND ipython.
whatnick
2009-09-25 08:27:28
It's a business decision. We have customers tied to either Java or .NET technology, and most of then wouldn't want us to install code foreign to their platform on their servers.
santiiiii
2009-09-25 08:32:09
+2
A:
What I find interesting is that you are looking at not duplicating the effort of unit tests, but not for the application itself. Why not write the application core & unit tests in say Java and then use ikvm and only have the UI levels in C# and Java with separate unit tests based around the technology right each. (Or Grasshopper if you you are a .NET shop)?
mlk
2009-09-25 08:34:12
What you say makes sense, but I'm not sure I trust any third party tool to transform the code from one platform to the other. I'd rather have control over what's going on. Besides, both implementations *should* be pretty straightforward.
santiiiii
2009-09-25 09:07:56
Are there any neutral languages that target both environments and support a compile to native byte code option? Python or Ruby say? Your clients would not need to know (unless they want to look at the source) as you would only be supplying compiled classes and an additional library.
mlk
2009-09-25 10:49:05
+3
A:
Cucumber is a great framework for writing specifications. The specifications are backed by step definitions, which could be written to drive both .net and java implementations.
rhys keepence
2009-09-25 10:29:45
+3
A:
There are a few other options for languages that run on both the CLR and the JVM. Some of those already have their own unit test frameworks.
For example, Ruby comes with Test Unit and exists in source compatible versions for both runtimes (JRuby and Iron Ruby - both of which are Ruby 1.8 version compatible.)
Would be a good excuse to learn Ruby if you don't already know it...
serg10
2009-09-25 12:04:37
To be honest, I really would like to find an excuse to learn Ruby.This may be it. I'll check Test Unit.Thanks
santiiiii
2009-09-25 15:21:37
+1
A:
I am author of jni4net, open source intraprocess bridge between JVM and CLR. It's build on top of JNI and PInvoke. No C/C++ code needed. I hope it will help you.
Pavel Savara
2009-10-31 19:49:40
It seems jni4net won't work on linux boxes, one of the requirements I have.
santiiiii
2010-04-23 08:26:32
More about Mono here:http://zamboch.blogspot.com/2010/04/jni4net-not-yet-on-mono-linux.htmlFancy to share your story with us to support your case ?
Pavel Savara
2010-04-24 19:24:50
+1
A:
I recommend re-examining the granularity of your question. It implies unit-testing but why not go to functional/system level testing. In this context, FIT becomes a choice.
As one example, we have a client-server app in Java. We use FIT as an alternate client: we can specify Html input files and with some glue (aka fixtures), we can hit the server.
The good news is that this is agnostic to the language on the server, and the Html files can be used as acceptance tests.
The bad news is that FIT is merely a framework: it can take a lot of glue. Also, one must realize that these aren't unit tests. Not only is the granularity different, but also the speed is different. i.e. A large set of tests may not run in 'normal' amount of time, from a unit-test perspective. (We run ours at night and only a small subset during CI build.)
Michael Easter
2009-10-31 20:12:25