Forum Discussion

New Contributor

7 years ago

How to work with many people on the same project/projects ?

Hi,

Before I describe the way we work I would like to ask some questions first. Please be aware, that we use TFS versioning control of the source files. We don't use Keyword tests.

- is it a good idea to share .pjs file among many testers ?

- is it a good idea to share .mds file/files among many testers ?

Depending of the answers for the previous question:

- Is it a good idea that everybody should have it's own and not shared .pjs file ?

- Is it a good idea that everybody should have it's own and not shared .mds file/files ?

We would like to share amoung all the testers as much code as possible. For now - we share absoulutely nothing between each other and everybody works just for himself. If I create a function, nobody includes this function to the code, so that everybody creates it's own function like:

def generateFakeMail():

We would like to change that, but we don't know how to do that in the best way. For now everybody has it's own pjs file and everybody has it's own mds file. Directory structure looks like this:

TestComplete 11 Projects
Tester1 automation
Tester2 automation

Tester3 automation

Every TesterX automation directory looks like this

TesterX automation

Project1

Project2

Project3

TesterX automation.pjs

While having structure like this - it is impossible for us to include anybody's file and keep the versioning control. For some reason - if I add the file outside my Tester1 automation directory and add something from Tester2 automation directory, this file is not being kept under versioning control inside Test Complete.

Please share your thoughts and comments about the best way that we should work. There are 6 testers in the team and I think that we should bo more focused about the projects, becouse more than 1 person works at the same project. That's why I think that sharing .pjs or .mds file might be a good idea.

I think maybe we should do something like this:

TestComplete 11 Projects

Project 1

Project 2

Project 3

It looks like sharing .pjs file or .mds file sounds like a great solution, however I had a problem in the past. It happend just once, but when it happened it was really annoying. The problem was like this:

- I created a project on first PC

- I copied this project to second PC

- I tried to run all the scripts on second PC - it worked terribly slow. To resolve my problem - I created new pjs file and mds files on second PC and just added existing items - scripts. It helped.

What are your suggestions about what we should change in order to share a lot and use a lot the common code ?

karkadil
7 years ago
The best way to work with MDS and PJS files is to keep common version under source control (TFS in your case). If you need to modify it, you have to check out the latest version, make changes and then commit the changes. Do not try to merge these files, most probably you'll get a broken file. Also do not simply commit your local file copy without checking out it first, because you can have a lot of changes in your local file copy and after commit it will affect all team members.

karkadil
Valued Contributor
7 years ago
The best way to work with MDS and PJS files is to keep common version under source control (TFS in your case). If you need to modify it, you have to check out the latest version, make changes and then commit the changes. Do not try to merge these files, most probably you'll get a broken file. Also do not simply commit your local file copy without checking out it first, because you can have a lot of changes in your local file copy and after commit it will affect all team members.
- tristaanogre
  Esteemed Contributor
  7 years ago
  I can't see, exactly, why you would want an architecture for developing automated tests where there would be no sharing of code units. Generally speaking, you're developing a project (MDS) for executing a series of tests. Unless each of your automation developers is testing a different application, to me it would make sense to have them all use the same MDS file. Likewise, the PJS file is the collection of all the MDS files in your space so, if you're all working on testing the same application, I would expect the PJS file to be shared as well. Then you would all be working on updating and developing the same code base and you would benefit from each other's work. Less "rework" being done, more efficient coding, and a consolidated test suite.
  
  As karkadil suggests, though, you should follow standard software development practices. Always "get" the latest version of the code base before you commit your changes. Depends on if you're using the TFVC or the git integration as to the specifics of your workflow, but yes, ALWAYS make sure you have the latest version from your repository before you commit any new changes.
  - AlexKaras
    Champion Level 3
    7 years ago
    Hi,
    
    And just to join to the above speakers:
    
    -- Yes, the more code is reused within the test project, the better;
    
    -- Merging is a trade-off and is a price that is paid because of distributed development. Merging must be avoided as much as possible;
    
    -- It is near to impossible to merge all files that compose test project in TestComplete. The only partial exception are files with test code.
    
    Thus:
    
    -- The less concurrency happens between developers for test code the better;
    
    -- If anyone needs to make corrections to any test project element except test code unit, then he/she must consider his actions first, notify the team, get latest version from the version control system (VCS), make changes as quickly as possible, verify changes correctness as quickly as possible, commit changes, notify team. Every team member must update from the VCS upon this notification;
    
    -- Changes to source code files must be committed to the VCS as often as possible. It is acceptable to comment-out (or otherwise exclude from execution) portions of code that are not finished yet. But committing to and updating from the VCS often you are lowering the risk of merge conflicts and the risk of all problems that are common to conflicted commits.
NisHera
Valued Contributor
7 years ago
Also to add to above comments..........

you would be better-off sharing single name maping file (NameMapping.tcNM) if it's same application.

but should be done very very very carefully..!

I mean everybody should use same pattern of mapping. (no single object mapped twice in deferent hierarchy)

initially one person would be responsible for maintain name-mapping.