confused on choosing test suite's language?

confused on choosing test suite's language? the K.I.S.S. answer is, let your test suite be in same language/environment as of the application. If there are multiple language used if the application, then choose a language that is used to define your application's models and their builders.

And the long answer...
Recently I came across a project where application was written in Java and the test suite was in Ruby. The reason for the choice of test suite’s language was that the tester in the team was conformable with Ruby, and the 'team felt that' it would be quicker to develop tests in Ruby.

Given the same scenario, if I were the tester I would have chose otherwise. Yes I would have faced difficulty in setting the initial framework in Java, since I would be less familiar with the language, and my churn of initial set of stories would be less.

Let me explain why I would have chosen the difficult path (though at the face it looks so, let me argue it is the other way). Below I would compare the various aspects and their effort with the test suite is in Ruby and the application is Java against both test suite and application in same language.

When application is in Java	and if tests are in Ruby	and if tests are in Java
To set up a development environment,	We have to spend effort in setting Java environment (JDK, class path, java_home, maven), and the Ruby environment (RVM, bundle, gem, rake ...). And the pain would be two fold considering the ground difficulties  (it work in that machine, and not in this machine)	All the effort spent/confusion in setting a new environment is saved
Setting test execution	Configure and set up test execution form scratch, I my experience though are familiar with a language every time new set of issues will be waiting for us to solve	Happily reuse the configuration and execution scripts developed for unit/integration tests done by developers
Setting CI pipe line	Every time you set a new box for your regression suite, same story as development environment will repeat here	Sit back and relax, if your app work test would work
IDE	Multiple ones, and do consider the cost associated with them	:)
Maintenance	Once you happily handover the project to the client, the poor guy have to find a person who is good with both the languages to maintain the code base	Skills is narrowed to a single language
If you choose to ignore all the above argument, here is a lethal one.
Test Data Set up	Whatever the approach you choose to use, be it writing your own model to match the application and builders (like factory girl) with that be reverse engineering the DB parsing the migration scripts using bridge (like jruby or ironruby) to use developer builders It would involve a heavy effort. Most likely it would turn dirty as we run behind to chase and match all the changes happening in your application model and their relations	go ahead and use builders developed for unit/integration tests

Irrespective of the languages (Java and Ruby) used in above argument, the issues remains same for any combination of languages.