Looking a version control solution which is easier in case of keyword tests

[testbuilder]

We are a team of 3 testers and we are using team foundation server for version control.

We use keyword tests for testing. 

What is the best way of sharing the code between 3 of our testers?

TFS does not seem to be working so well for you since we have keyword tests and merging them is very tedious

We are looking a version control solution which is easier in case of keyword tests

I have seen a blog on test complete website about sharing the code in a network drive. Was wondering what will be the pros and cons of it. (https://support.smartbear.com/testcomplete/docs/working-with/teamwork/sharing-projects.html)

[tristaanogre · Accepted solution]

Just an FYI, the very structure of a KDT file is not going to play 100% nice with most version control systems out there.  KDT files are a type of XML.  Generally, that wouldn't be a problem.  But because it's not standard coding structures and the tagging isn't always clear, version control systems' auto-merge capabilities don't always play nice. 

Generally, as a rule of thumb, I suggest that, if you have a team of folks, don't have more than on person working on the same KDT file at the same time.  Likewise, don't have them working on NameMapping updates at the same time.  

As for sharing code on a drive... that's OK... but it's not ideal.  Everytime one person clicks "Save" on the project, the other will get a message "Hey, the file updated.  Want to refresh?"

All.

The.

Time.

If you DO need to have two people working on the same KDT at the same time, best thing to do is manually merge their steps within the TC editor and not use the auto-merge of your source control system.

[hkim5]

Hi,

No matter what version control system you use, merging will become a problem if you have different individuals accessing the same files concurrently. As you can imagine, different people will do different things, and making multiple changes from different locations and merging them together will create problems, not only with keyword tests, but also with TC scripts, and with your other more traditional scripting solutions as well. I'd suggest following certain guidelines when it comes to your testers pulling the code. Many articles have been written across multiple different platforms on how to avoid merging conflicts (i.e https://medium.com/front-end-weekly/avoid-80-of-merge-conflicts-with-git-rebase-b5d755a082a6 )

Of course, you could still choose to save to a network drive if that's what you want. You could either set that one drive (etc.) as the default project location, or you could also set a workplace rule to "save as" your project at the end of the day when you're done modifying the files. However, one foreseeable shortcoming is that this isn't really a robust way to set up your repository when it comes to parallel builds using CI frameworks. But if that's not currently within the scopes of your workflow, then saving to a network drive may work. This still wont really solve your problems, since there will no longer be a central source of truth for your keyword tests, since i am imagining that your testers will start to overwrite each others' works if they just save to the same location. If not, then you will end up with duplicate project suite files (at best).

Keep us updated with your solution 🙂

[testbuilder]

Thanks @tristaanogre 

Really Appreciate your input. 

We are avoiding working on a same KDT but sometimes it becomes hard in case team works on same KDT and there are merge conflicts. 

[AlexKaras]

@testbuilder 

---

@tristaanogre wrote:

...

Everytime one person clicks "Save" on the project, the other will get a message "Hey, the file updated.  Want to refresh?"

All.

The.

Time.

And note that TestComplete implements the 'last writer wins' strategy which means that:

-- If you agree to refresh you will lose the content of your local file;

-- If you refuse to refresh and save your file later, you will overwrite the file on the network share and the changes made by other person will be lost.

P.S. I do hope that SmartBear will implement the possibility to visually merge the content of of files to be refreshed so that the one who is refreshing can incorporate required changes from the changed file and not to lose the content of the local file.