Puedo envolver una función de Java como esta:
* def myJavaMethod = """ function() { var Utils = Java.type('Utils'); // use Number type in constructor var obj = new Utils(...); return obj.myJavaMethod(); } """Pero ¿por qué lo haría? Puedo usar las funciones de Java directamente en los escenarios de prueba, como este:
Scenario: Test exec and error value * def Utils = Java.type('Utils'); * def ret = Utils.exec('echo "From Java" > /home/richard//karate-test/karate-0.9.6/out.txt'); * match read('out.txt') == "From Java\n"; * match Utils.exec('exit 123') == 123 Nota: exec es un método estático que usa un shell para ejecutar el comando dado.
Al menos probé esto para métodos estáticos y funciona bien sin el desvío de JavaScript. Parece que el contenedor de JavaScript solo agrega una capa adicional de complicación. Además de eso, con la sintaxis de 'llamada' solo puedo pasar un parámetro (que ciertamente puede ser un objeto completo o una matriz). Pero puedo pasar parámetros directamente a una función de Java (usando la sintaxis normal) e incluso usar el resultado en una coincidencia. (Supongo que los parámetros y los resultados se convierten implícitamente en un valor de JavaScript, que podría ser un objeto o una matriz JSON).
Hasta ahora, extraño ver la ventaja de envolver explícitamente el código Java dentro de los envoltorios de JavaScript. Supongo que el problema soy yo, es decir: ¿me estoy perdiendo algún punto importante aquí?
La única ventaja es reducir la escritura y cuando tienes mucho código reutilizado. Por ejemplo, en lugar de:
* def foo = java.util.UUID.randomUUID() + ''Lo defines una vez:
* def uuid = function(){ return java.util.UUID.randomUUID() + '' }Y luego llámalo donde sea, y es súper conciso:
* def json = { foo: '#(uuid())' }