Drupal Testing: Interpreted Code vs Compiled Code in Frameworks

• This stackoverflow post embodies why I go for compiled code IN TEST ENVIRONMENTS
  • https://stackoverflow.com/questions/3265357/compiled-vs-interpreted-languages#3265602

This comment targets my sentiment:

As a QA automation stakeholder, I want as LITTLE VARIATION AT RUNTIME as possible

• Any bug in the framework at run-time is extremely expensive
• Strongly-Typed languages FORCE self-documenting code
  • This does what exactly?
    • var a = 12345
    • var b = "6789"
    • var c = a +b;
  • The tester's intent is absolutely clear, so we know if its automation bug or product bug if an evaluation fails
    • int a = 12345;
    • String b = "12345";
    • int c = a + b; <-- results in compilation error
      • this problem is resolved BEFORE the test logic is assumed correct & used for test
  • LOGIC ERRORS IN TEST FRAMEWORK CAUSE FALSE POSITIVES
    • This is lethal... product goes out with catastrophic datatype or logic errors whose values are happily consumed by the scripting language and frustrating to debug
    • Even if false positives are produced by Strongly-Typed language, the debugging process is trivial because the code is very explicit on its intent.
      • Engineer has an opportunity to understand coder's intent & can evaluate if that intent is faithful to the test case directive.
•  

When Interpreted Scripting Language Make Sense for 'Testing'

If the choice is between 'no test' & 'test in native language', then the business case is there to use scripting languages( interpreted languages ) to 'extend the product' to be 'self-testing' using the native language. Keep in mind that EVEN IF SAME LANGUAGE USED for development & automation test, THE TEST TOOL MUST BE AUTONOMOUS with no dependency or shared resources with the SUT ( System Under Test ). If there is ANY affiliation between SUT & Automation, it will be considered WhiteBox....and possibly Unit Testing. When QA performs an evaluation, it MUST occur on the product in its 'production state'. This given, seems that unit test automation SHOULD be in the native product language to facilitate WhiteBox capability & developer involvement with developer best practices.

QA Engineers May Not Be Software Developers

Strongly-Type Compiled Languages for programmers to adhere to stricter standard with their code. You'll have to make a conscious decision to do something wrong - the compiler won't fix bad ideas, just bad assignments & evaluations.... Upon a compilation error, the programmer must decide if the data type assignment should be a String or Integer and commit with all the dependencies. Scripting languages will swallow integers as strings, so if an error arises, one must debug both the application AND the automation framework.

Java ecosystem is largely free for non-enterprise, often used in introduction programming classes, has a hardened compiler that has been revisioned & used by the most intense environments in business, has a huge user base, has a massive population of HARDENED libraries, & has implementation in nearly all IDE & testing solutions. As such, the entrance criteria for ramping up test teams is lowered considerably when the dev environment only includes a path reference. Many scripting langauages require some sort of multi-layered client or server environment that MUST be up & running to provide the interpreter during RUNTIME.