What are the benefits of using dedicated testing languages for writing tests?

Question

What benefits do you see in using a dedicated testing language instead of a general purpose language for writing tests? What is the advantage of using TTCN-3 or a proprietary testing language?

Answer 1

Well, the original question had two aspects. Proprietary testing languages and TTCN-3.

While I totally agree with the answers towards the proprietary/vendor languages, I would definitely not include TTCN-3 into this discussion.

TTCN-3 is a multi-purpose, internationally standardized and therefore nonproprietary test language. I frequently get the question: "Why should I use TTCN-3 instead of my programming/scripting language X?"

Of course you can always you use a programming language to solve a problem like test automation.

Basically you should choose your technology on how efficient you can solve your problem. But writing the test is only part of the game. So whether you are familiar or an expert with your favored language does not answer the related questions. Namely where do I get the test framework or the test execution environment, the reporting capabilities, etc. Of course I assume that your do not want to invent everything on your own.

Now the normal working assumption is that you can achieve all of your goals only with "normal" programming languages.

But if your consider what you are really looking for, which is most of the times - easy to use but yet powerful - extensible - no vendor lockin - good tool support on the right level - fits into your processes - etc.

then you could consider TTCN-3 as one candidate.

As stated earlier it is a standardized, multi-vendor supported DOMAIN specific language. And the domain is testing. Nevertheless it has tried to take the usual concerns of testers as well as from testers into account. So you can extend a test TTCN-3 based system in Java, C, C++, etc. You can even integrate your own tools and environments and still profit from powerful test environment(s).

So, the next time you are looking into a test automation that can be used like a normal language but give the feature richness and very good tool support, perhaps you make a short search for TTCN-3 and give it a try.

Answer 2

To paraphrase & quote Lessons Learned in software testing

"We see no compelling reasons for vendor scripts." ...

• They make coding difficult
• They are hard to learn
• They interfere with the collaboration between developers and testers
• It is hard to build on the work of others

See the book for the full description of these. I would personally add :

• It makes recruitment more difficult as you need to search from a much smaller talent pool

• You are beholden to the vendors skill as a language and software development environment provider.

• You are now locked in to a single vendor.

And I personally see no benefits. When you start talking about widely adopted, open, domain specific languages like Gerkin, that is a different story.

Answer 3

I agree with Bruce - I see no benefits.

I happen to be currently using a tool with a Basic-like proprietary language. It's a terrific tool and does much of what I need. The language is full-featured, easy to learn, and well suited to our tasks and our style. I have no complaints.

Still, it would be even better if it were non-proprietary language.

Answer 4

Proprietary testing languages are beneficial for those who sell proprietary testing languages. They are also beneficial for certain consultants, technical book authors, technical conference speakers, and testers who need more words on their resume. For all others, not beneficial.

One would not test screws with a hammer. In the same sense, for a given environment there will be a language that makes more sense for testing than another. This is not because testing requires special language features or a simpler language.

Sometimes it is easier to express a test in a specialized language because the syntax of your default general-purpose-language gets in the way. This is the exception rather than the rule. As much as they would like to help, the proprietary testing language vendor does not understand your tests well enough to help you.