Forum Discussion

Abitha_iCare's avatar
Abitha_iCare
New Contributor
7 years ago

Am preparing "Code Quality Guidelines" document for Ready API. Need inputs...

Hi All,   Hope all are good.   Am preparing a guidelines document for Code Quality of Ready API. Can you please provide your inputs...   Regards Abi
  • rlong98's avatar
    rlong98
    7 years ago

    Oh - so this is for your team "Users of ReadyAPI" ?

     

    I normally write to fit both team & business so that it's simple to lead junior testers as well as speak to Business non-technical.

     

    In that case I always find typing like I'm writing in grammar school lol.  It really does work out kudos.

     

    DYNAMIC CODING - API TESTING 

    Field Population will be dynamic by utilizing "context" expressions that will pull the field value from an external Data Source (i.e. Excel, Oracle...) to test an unlimited amount of test scenarios.  This will eliminate manual maintenance of the API testing, allowing the test to run automated on various test scenarios...

     

    Here I would put in a picture (see attached)

     

    The next phase of your document will be to write up Updating Definitions and/or Refactoring - if the WSDL/WADL changes... :catfrustrated:

    Which depending on HOW MUCH is changes can the Refactoring work - otherwise you screwed... and sadly the Refactoring for me has worked minimal. 

    1. Always start off with Updating Definitions.  Usually I only have myself or the test lead to do that and store the project in SVN or Git because it can get messy.

    2.  There are tricks in Notepad++ if Refactoring doesn't work... say if the XPath doesn't match up anymore - you can Find/Replace - - but that's when nothing works from Refactoring.

     

    Rob

     

     

     

     

rlong98's avatar
rlong98
Contributor

Hi Abi,

 

I'm guessing you're referring to a document to "prove quality" ?

Since "Code" is very minimal in ReadyAPI - the Quality is more around the "Quality of the Test Suite Project" - and Directors / Business will look for:

  • Repeat-ability of the test Suite (which we know from our build of an API - it is)
  • The Maintenance of the Suite (How much work will it take to maintain or grow the project)
  • The Dynamic Ability - (Data Source vs. Manual Entry
  • (You will fail in any delivery of a document if there will be any manual entries needed in an API)
  • Running & Reporting:  If someone needs to open ReadyAPI and run it, that's sort of ok, but most prefer it run by Command Line, included in a Selenium project w/ reporting.

As for Addressing Code  - it's "how you go about the above"

  • Groovy Scripting code (where it's kept) Groovy Script step, Setup/Tear Down in a testSuite.  How it helps in keeping the project dynmaic - whether it calls a DataSource, or Resets the API's to Ready, Changes any values etc...
  • If you have cool reporting tricks where using ONE API and Looping the API where many intense projects we built will use Groovy to add Elements instead of cloning a testStep.  Then reporting the results of each is a Win with Business.  Any good reporting is.

Not sure if that is what you were looking for... Hope it helps.

 

 

 

Abitha_iCare's avatar
Abitha_iCare
New Contributor
7 years ago

Hi,

 

Thank you for your reply. This is pretty much suits my expectation. But I need more on "What is the wise way of using Ready API". This will help the new comers to the team to understand what to be done.

 

For example : Use GetData() instead of hard coding, etc...

  • rlong98's avatar
    rlong98
    Contributor
    7 years ago

    Oh - so this is for your team "Users of ReadyAPI" ?

     

    I normally write to fit both team & business so that it's simple to lead junior testers as well as speak to Business non-technical.

     

    In that case I always find typing like I'm writing in grammar school lol.  It really does work out kudos.

     

    DYNAMIC CODING - API TESTING 

    Field Population will be dynamic by utilizing "context" expressions that will pull the field value from an external Data Source (i.e. Excel, Oracle...) to test an unlimited amount of test scenarios.  This will eliminate manual maintenance of the API testing, allowing the test to run automated on various test scenarios...

     

    Here I would put in a picture (see attached)

     

    The next phase of your document will be to write up Updating Definitions and/or Refactoring - if the WSDL/WADL changes... :catfrustrated:

    Which depending on HOW MUCH is changes can the Refactoring work - otherwise you screwed... and sadly the Refactoring for me has worked minimal. 

    1. Always start off with Updating Definitions.  Usually I only have myself or the test lead to do that and store the project in SVN or Git because it can get messy.

    2.  There are tricks in Notepad++ if Refactoring doesn't work... say if the XPath doesn't match up anymore - you can Find/Replace - - but that's when nothing works from Refactoring.

     

    Rob