Why Java (or C#) is not suitable as a functional testing language?

By mark

One key difference between automated functional test scripts and application code is their target audience. The application code is developed and maintained by programmers, while the test scripts may be developed, executed and maintained by testers, developers, business analysts and even customers (_this backed by the fact TestWise is the most used software product for projects I know using it_).

The fact is that testers, business analysts and customers generally do not possess strong programming skills, and this changes the whole paradigm. It is not hard to imagine that a 85MB download of Eclipse (a Java IDE), configuration of library path and JDK path will do to a non tech-savy tester as the first chapter of automated testing orientation program. And you might hear screaming minutes later: "What does 'compiler error' mean?".

I believe automated tests shall use interpreted/scripting languages (such as Ruby) instead of compiled languages (such as Java), maybe that's why they are called "test scripts". And as a functional test script language, it should have following characteristics:

  • easy to learn,
  • no compilation required,
  • non proprietary,
  • concise, readable syntax,
  • extensible syntax to use domain specific language,
  • and ideally, one operation per line

From experience, it is not a good idea to force testers (or chosen for them) to use same tools as developers. The irony is: testers need constant help from developers, and this inadvertably put testers in inferior position to develop independent tests to verify developers' work.

Finally I show you an excerpt of automated test scripts from a Java project (jWebUnit)

    try {
  Date date = new Date();
  SimpleDateFormat simpleDateFormat = new SimpleDateFormat("dd/MM/yyyy");
  String yesterdayString = simpleDateFormat.format(date.getTime() - 24 * 3600 * 1000);
  assertTextInElement("receiptDate", yesterdayString)
} catch (Exception ex) {
  throw new RuntimeException("receipt date check failed")
}
  
And here is the version using rWebUnit
    label(:id, "receiptDate").should == yesterday