Forum Discussion

Jen_ReadyAPI's avatar
Jen_ReadyAPI
Occasional Contributor
3 years ago
Solved

Newbie Question: Naming standards in ReadyAPI

Hi,

 

FYI - I am new to API and HTML and Ready API - so may explain if my questions sound daft - or if I've incorrectly expressed things.  Just still finding my feet.

 

My questions:

What is the naming standards in ReadyAPI - if there are any?

 

Also how do I do this efficiently?  It would be laborious to rename each item individually.

 

This is how I have labelled my trial.

 

Any advice will be appreciated.

 

Jennifer

  • Hello Jen_ReadyAPI ,

     

    A little planning before you start will go a long way...  There is no naming convention/standard.   My advice is to take a little time and discuss with your teammates what would be best.  Above all, try to remain consistent with whatever convention you decide upon.  If you can't think of anything else, schedule a meeting with your developers of what you are testing.  They will probably have a naming convention that you could incorporate into your testing naming convention.

     

    Since a ReadyAPI project structure is consistent...

       Project -> Suite -> Test case -> Test step

    You really just need to focus on convention for these four things.  My experience is that Suite name and Test case name are the most important to concern yourself with. 

     

    Lets start with project name/type:

    If you are using a repository for files, you want to consider using a composite project.  If you are working with your projects individually, a normal/standard (monolithic xml file) is easiest.  If in a repository that contains other project types other than ReadyAPI, consider using the actual word "ReadyAPI" in your project name.  ReadyAPI typically does that for you when creating a new project.

     

    Suite name/Testcase name:

    I try to make these consistent upon what I am testing and name them such that I can trace back to the feature that the developers are implementing.  They don't necessarily need to contain the word TestSuite or TestCase since you sort of know already what they are based on their position in the hierarchy.  TestSuite name might just be the api you are testing or one of the methods of an api you are testing.  I tend to have long test case names since I don't use the test case description area often.  I also take some advice from cucumber bdd (Behavior Driven Development) in test case naming by using 'Given', 'When', 'Then' structure (i.e. a test case name of: "When Customer Is Inactive Then Response Token Is False").

     

    Step name:

    I tend to use mainly Groovy steps for most all test steps.  I did follow the practice for a long time of prefixing the step name with the value of the test step I was inserting from the "Insert Step" item list.  Just starting out, this might be of good help, but as my teammates pointed out since everything was a groovy test step, why prefix with each with "Groovy Script"?  Now I just name them as descriptively as I can so that other reading it will know what that step does.

     

    This is just a small experienced answer, but just start doing what you or your teammates seem best.  As you go, you will define things better than the last time you did it.  keep improving and as you see fit, go back and refactor as needed.

     

    Regards,

    Todd

     

3 Replies

  • TNeuschwanger's avatar
    TNeuschwanger
    Champion Level 2

    Hello Jen_ReadyAPI ,

     

    A little planning before you start will go a long way...  There is no naming convention/standard.   My advice is to take a little time and discuss with your teammates what would be best.  Above all, try to remain consistent with whatever convention you decide upon.  If you can't think of anything else, schedule a meeting with your developers of what you are testing.  They will probably have a naming convention that you could incorporate into your testing naming convention.

     

    Since a ReadyAPI project structure is consistent...

       Project -> Suite -> Test case -> Test step

    You really just need to focus on convention for these four things.  My experience is that Suite name and Test case name are the most important to concern yourself with. 

     

    Lets start with project name/type:

    If you are using a repository for files, you want to consider using a composite project.  If you are working with your projects individually, a normal/standard (monolithic xml file) is easiest.  If in a repository that contains other project types other than ReadyAPI, consider using the actual word "ReadyAPI" in your project name.  ReadyAPI typically does that for you when creating a new project.

     

    Suite name/Testcase name:

    I try to make these consistent upon what I am testing and name them such that I can trace back to the feature that the developers are implementing.  They don't necessarily need to contain the word TestSuite or TestCase since you sort of know already what they are based on their position in the hierarchy.  TestSuite name might just be the api you are testing or one of the methods of an api you are testing.  I tend to have long test case names since I don't use the test case description area often.  I also take some advice from cucumber bdd (Behavior Driven Development) in test case naming by using 'Given', 'When', 'Then' structure (i.e. a test case name of: "When Customer Is Inactive Then Response Token Is False").

     

    Step name:

    I tend to use mainly Groovy steps for most all test steps.  I did follow the practice for a long time of prefixing the step name with the value of the test step I was inserting from the "Insert Step" item list.  Just starting out, this might be of good help, but as my teammates pointed out since everything was a groovy test step, why prefix with each with "Groovy Script"?  Now I just name them as descriptively as I can so that other reading it will know what that step does.

     

    This is just a small experienced answer, but just start doing what you or your teammates seem best.  As you go, you will define things better than the last time you did it.  keep improving and as you see fit, go back and refactor as needed.

     

    Regards,

    Todd

     

    • Jen_ReadyAPI's avatar
      Jen_ReadyAPI
      Occasional Contributor

      Thank you Todd.

      I will keep your suggestions for when the time comes.

      Jennifer

  • nmrao's avatar
    nmrao
    Champion Level 3
    There aren't any. You can name it how you feel it is good. If working in team then you all need to co-ordinate and follow what you decide.