Forum Discussion

ChrisA's avatar
ChrisA
Contributor
7 years ago

General Question : Why do so many SoapUI users appear to use Groovy scripts to run tests?

Hi,

 

Apologies, this is just a general question and not an issue.  I've been using SoapUI for about five years now.  In the main, I have used it for testing a set of SOAP Services and a RESTful API.  I have many test suites and test cases for their own purposes and I run these from the SoapUI GUI.  On occasion, I have run suites from the command line, so I can see the use of that.

 

I use Groovy scripts to help fill the gaps between test steps when I find I cannot use one of the pre-existing test step types.  I've also used them for complex checking or calling an external Groovy class.

 

What I'm not clear about is why I see so many posts on here and on sites like Stack Overflow where people are using Groovy script to run tests.  In the examples, they select a suite and test.  They run steps, they run assertions on the responses.  At this point, you're probably thinking what wrong with that?  But I'm seeing these examples in a single script.   Here's one such example soap-ui-dynamic-value-from-request-content.

 

What benefits does building test cases in this way have over using the GUI?  I feel like after all these years, I missing something fundamental, but I really don't know what.  I've always managed to be able to use the GUI to define my tests and run them and keep Groovy scripts there as fallback.  Or is it a case that people aren't taking the time to understand the GUI and are resorting to Groovy because that's the only option they see.

 

13 Replies

  • StevenColon's avatar
    StevenColon
    SmartBear Alumni (Retired)

    Thank you for posting to our Community Forum.

     

    In my experience as a Support Engineer, users resort to mainly scripting for two reasons:

    1. Scripting gives them greater control of their testing which is needed for their project requirements
    2. They have alot of coding experience and prefer using a series of scripts.

    ReadyAPI provide this flexibility to users so that you can choose how you want to construct your tests. One way isn't inherently better than the other.

     

    I am interested in hearing from other users who have decided to use mainly groovy scripting in ReadyAPI since this choice is really on a case by case basis depending on experience and projects.

     

    Have a great day!

    • ChrisA's avatar
      ChrisA
      Contributor

      Hi Steven,

       

      Thank you for the reply.  Hopefully, other users will reply and explain their reasoning for taking the script based approach.

       

      Regards,

       

      Chris

  • I various reasons for using Groovy. In one case I needed to make a system call to run a bash script then format the standard output and feed the output into the value part of a json object for the request.

     

    In another case I needed to read in a response value from the previous step and put that value in a json object for another request. 

     

    And then I had some json requirement that had two words (blank space) in some name fields. I needed to work with Groovy to get that going.

     

    I use Groovy in the assertion script to check for a specific value in our case "Success"

     

    I also use Groovy at the test suite level Setup Script to set the SSL keystone password and keystone location.

    • ChrisA's avatar
      ChrisA
      Contributor

      Hi Bill,

       

      Thank you.  These are just the sorts of things I use Groovy for too.  IMHO, it's the ability to script where there isn't a standard step that makes SoapUI so powerful.

       

      Chris

       

       

      • nmrao's avatar
        nmrao
        Champion Level 3
        ChrisA,

        SoapUI provides user to utilize the power of groovy within the tool.

        Generally, I put the groovy scripts related to SoapUI in my github repot, may be it is possible to refer in case if there is a need.

        https://github.com/nmrao/soapUIGroovyScripts

        Of course, you can search for similar questions here in this forum or stackoverflow as well.
  • nmrao's avatar
    nmrao
    Champion Level 3

    ChrisA,

     

    I feel that you know well when do you need to use the Groovy Script test step and other have also provided when do they use it.

     

    I would like to add my 2 cents answering / clarifying your question.

     

    • It all depends on the need and do not think that you are not using it(running tests from groovy script step) or missing something.
    • Some people use it because of their use case or situation. It does not mean, every body needs to use it in the same way.
    • Some people use it though it is not required just because they see some code some where or use it incorrectly / inappropriately. The example link you pointed is correct example for this kind. If you look at answers, 3rd one is mine (luckily happen to be there for the cited example) where it is possible to achieve the same thing (as author of the question wanted) with much lesser code and without needing to run the test step (which your main point in the question) as part of Script Assertion(that means without even needing to have an additional Groovy Script test step).
    • Some people run a project or test suite from a groovy script test step of different project and that is not the right way to use it.
    • The tool can be used to design your tests and try them. Once the project is ready, use the SOAPUI_HOME/bin/testrunner.bat (.sh) to execute the project from command line.
    • Some people have dependency between the projects or suites which is again not the right way. I believe that each test should be independent.
    • ChrisA's avatar
      ChrisA
      Contributor

      Hello Rao,

       

      You make some good points here, thank you.

       

      Re

      • Some people run a project or test suite from a groovy script test step of different project and that is not the right way to use it.
      • Some people have dependency between the projects or suites which is again not the right way. I believe that each test should be independent.

      I agree, these approaches don't make sense to me, but after seeing a few posts I did wonder whether I was missing out on something useful.  My first thoughts were "why would you want to do this?", but after seeing a few simlar posts, I then started thinking "is there a gap in my SoapUI knowledge?  should I be exploiting this myself?"  But, I couldn't think of practical reason in my test activites why it would be beneficial, so I asked here....

       

      Thank you.

  • testhrishi's avatar
    testhrishi
    Frequent Contributor

    "For loop" gets very easy to use with groovy. As I find conditional goto and datasource loop a bit confusing.

    Date/data manipulation is also possible with groovy

     

    Thats only when I use it.

    • ChrisA's avatar
      ChrisA
      Contributor

      Yes, Groovy is fab for data manipulatin and complex assertion checking.  Thank you.

  • larsn's avatar
    larsn
    Contributor

    I think many answers are misunderstanding your question as I understand it.
    I read your question as why are users using Groovy to run test cases.
    I'm aware of two situations, one is to use a previous test case as a setup for the current test case. The second is using a test case as a library call - this is when the library procedure needs to make a HTTP  request to the system under test and these requests are not done via Groovy.

    • ChrisA's avatar
      ChrisA
      Contributor

      Hi,

       

      Re your comment... I think many answers are misunderstanding your question as I understand it.
      I read your question as why are users using Groovy to run test cases.  Yes!  Exactly that.  I use Groovy scripts and external Groovy and Java classes an awful lot, but within the confines of my tests.  I don't use Groovy scripts as a means to launch a series of test steps, which to me forms a new test.

       

      Your example of using a Groovy to launch a test as a set-up step (pre-requisite) for another test and library calls makes complete sense.

       

      thank you.