Forum Discussion

smadji's avatar
smadji
Contributor
8 years ago

git commits for readyAPI files

I wonder how other people handle git commits for their saved tests.

 

I have a few projects which hold 1000s of tests. We run them often and every time a file is executed - we get file changes to commit. And internal guids change which causes differences.

 

If I run those tests on one machine and a colleague is running the same branch on another machine, we often end up with 100s of conflicts. 

 

Is there a set of files that we can set to ignore in the commit?

Is there a setting that prevents those GUIDS from changing while running the tests?

 

I know there is an option to run a tear-down script, which I have implemented in the past - it is not 100% solution and since my tests generate random data - I would like it to stay there until after they run so if I get a fail I will be able to investigate.

 

How do other people handle this? what does smartbear suggest?

 

Thanks

Smadar

5 Replies

  • testhrishi's avatar
    testhrishi
    Frequent Contributor

    I hope you are only saving tests and not the results to Git

    I have a composite project and I did not see any trouble checking in and out of Git so far

    Also if your intent is just to run the tests, make sure you do not save the readyAPI project every time you open it, that may save slightly different copy of it and hence the conflicts.

    Also make sure all are running the same version of readyAPI, else I have seen issues with different versions opening and saving files

    Hope this helps

    • smadji's avatar
      smadji
      Contributor

      I have ReadyAPI set to save every few seconds (because in the past it crushed on me while working, and I lost hours of work).

      Do you think that contributes to my conflicts?

      I have the project on sourceTree because we are doing continuous integration. When source tree is opened, and I open readyAPI, immediately I see 2 files changed and ready to commit (by just opening readyAPI). I believe one of those files is the workspace file so I should probably remove it from the repo...

      • testhrishi's avatar
        testhrishi
        Frequent Contributor

        agree with nmrao's comments. One more thing I usually is I never commit the tests from the location i run them. So I always do Pull when necessary and run the tests. So atleast i don't have to go through conflicts for regression suites. And I assume all the committed ones have already been taken care off.

  • nmrao's avatar
    nmrao
    Champion Level 3
    I believe you should avoid checkins if you just execute the tests.

    If you use testrunner.sh/.bat utility to execute the tests, then (based on the preferences set) it will not save the runtime changes to that project.
    • smadji's avatar
      smadji
      Contributor

      I guess I am not as advanced a user as you are. 

      I am not sure how to run my tests the way you described and avoid changes to the file due to run. That would probably solve a lot of problems. Can you point me to documentation on running the tests from command?

       

      However, since many of my tests relay on data from previous steps (via xpath) and assertions use x-path as generated by the test - I often get fails that are caused by changes of where the data is showing (since the xpath is looking for a specific line in the response).

       

      My tests have 1000s of steps, and I slowly - as thing fails - started updating the xpath to @name='field name' which prevent those fails from reoccurring.  But since I do it upon fail - I make changes to my tests while running them, and I do want to commit those changes.