Hi All,

We are using TM4.1.5 and Composer.

I'm finding it quite challenging to test our Groovy scripts; the Groovy console is a bit clumsy and I find I have to do a lot of manual work to run a test. Need to copy a service, manually copy paste service parameters, manually change values in the script, then run it, review, debug, repeat and so on.

What is your approach to testing? Do you:

  • have two versions of a script - one active and one for testing
  • have conditional statements e.g. 

    if (testing)
    do this
    do that

  • have a test script that calls the production scripts and manipulate inputs and results in the test script
  • some other options


We only use the groovy console, we don't have an IDE for development work (that's another topic)

Any ideas would be appreciated.




    CommentAdd your comment...

    2 answers


      Hey Mark,

      could you clarify a few things for me in relation to your query:

      1. Why do you need to create a copy of the service to test it?
      2. Why do you need to manually change values in the script?
      3. I'm interested in your point about not having an IDE - can you elaborate?

      Certainly I would not recommend you have branching logic in your script for test scenarios. In my experience this is not required.

      Some techniques that may help you:

      1. Managing multiple service endpoints and credentials for external service calls will allow you to quickly switch between test and prod environments where you are calling external services.
      2. Externalize values that you need to change as service parameters or input parameters. You should not have to modify the Groovy script itself to perform a test.
      3. Utilize the in built Unit Test feature to verify your service under a range of different scenarios by setting request parameters before executing the script and checking response values.

      You are on quite an old version of Avoka Transact, and as always we would encourage you to upgrade your environments on a periodical basis.

      Version 5.0 has excellent support for IDE development of groovy services which is a far better development experience than using the groovy console. More info.



        CommentAdd your comment...

        Hi Ben,

        I have inherited this system and found a few shortcomings.

        There is no test structure to speak of, so I find that I need to use the Groovy console as my test framework - copy the service, manually change values, execute script, debug, repeat, etc. This is not ideal, but until I get a decent test framework and write the test scripts I'll have to work with what I have available.

        All our development work for Groovy scripts is done using the Groovy console - that is our Groovy IDE at the moment. I'll introduce IDEA to at least get some productivity features for coding.

        I'm not a fan of conditional logic in production code, so I agree with your recommendation. The service endpoint article should be of some help. And externalizing 'variables' will also help, but that will involve quite a bit of code refactoring (just need some time for that to be done).

        When you mention the built in Unit Test feature do you mean the 'Test Service' tab on the service definition page? or is there something I'm missing because of our version of TM? Do you have any KB articles or other information regarding how to utilise the Unit Tests?



        1. Ben Warner

          Hey Mark, yes the tab on the service definition page is the one I'm referring to. In more recent versions this has been renamed to Unit Test but is essentially the same thing - lets you write a groovy script to test your service without having to use the groovy console. This article give some brief instructions for Unit Testing Groovy services: https://support.avoka.com/kb/display/SDK50/Unit+Testing+Groovy+Services Also, if you view the javadoc link from the Groovy Console and search for MockEntityService and MockRequestContext for information around setting up test scenarios.

        2. Mark Murray

          I'll investigate that article a bit further. Thanks Mark

        CommentAdd your comment...