Forum Discussion

jasond's avatar
jasond
Occasional Contributor
5 years ago

Process: Cleanup & order REST Resources

Community Question: How do you orginize your endpoints & request tests?   Problem: Our REST resources keeps growing & growing, when it was 20 requests for an endpoint it was easy to build & navig...
REST
nmrao's avatar
nmrao
Champion Level 3
Possible to show the problem with the help of a screen shot?
jasond's avatar
jasond
Occasional Contributor
5 years ago

I don't think I'm doing anything special in any way.

 

-API Endpoint

 -- Project

  --Test Suites (6)

   - Tests Cases (60+)

      - Tests (100s)

 

I'm currently building Story Tests, End 2 End & Regression tests. Each time I update the definition I get a few more REST Services (64 to date) to build tests for, This can be a few story tests, then duplicate into regression &/or E2E.

 

The issue is manageability. The product does not clearly indicate/highlight newly added REST Services, at least prior to 3.0 they would list at the bottom - so I have to hunt.

My tree view is pretty wild now, it just seems that there should be a better process.

 

  • nmrao's avatar
    nmrao
    Champion Level 3
    5 years ago
    Do you mean to say that the development of the rest services is in progress and you get new services or update in the schema each time which resulting you to redo the building / updating of requests (in case of updates)?
    • jasond's avatar
      jasond
      Occasional Contributor
      5 years ago

      Correct.

      This is a new API service being built from scratch. As new REST service calls get added I update the definition to get the new services to test.

      According to the project report I'm at 599 test steps, in 75 cases, in 6 Suites

      • nmrao's avatar
        nmrao
        Champion Level 3
        5 years ago

        This is the typical issue in almost projects when development and test automation are being developed in parallel, especially from the scratch.

         

        Certain things go well as designed and some not. So they have to be reworked to make them work.

         

        IMO, it would be good time to start for automation at least the wadl/swagger definition is fixed/concrete. Otherwise, will end up in re-doing. Also people should realize that it is not that test automation alone needs rework, development team is re-working on the particular service. So, am afraid if there is way avoiding it.

         

        Now, only thing to be focused is how to minimize the efforts to handle the situation to cater to services updates in the test automation.

        And there is no pre-defined / standard way to adopt this. Many be people can come up with tools and ideas over some time and experience. It can depends on different parameters such as 

        - how the tests are designed

        - is the new update requires additional properties (in the request)

        -- mandatory or optional

        - is the new update removed/renamed existing properites

        - how many request impacts tests

        - if working closely with development team, analyze definition changes before implementing the services and

        - and quick feedback of the impact

         

        Overall if one has good programming skills, he/she can explore to see if automatic update of the requests in the projects is possible (only if it is faster than manual update).

         

        Also it can be explored to see if the project itself be generated automatically with just inputing swagger/wadl file.