We are building a new experience for our SmartBear Community.
This site is now read-only. You can still browse and search as usual. Learn More
This site is now read-only. You can still browse and search as usual. Learn More
Forum Discussion
Solved
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.
- i...
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.
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.
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.
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.
