Forum Discussion

mfoster711's avatar
Regular Contributor
3 months ago

Using Github with TestComplete - Good or bad idea?

We have never used a source control but I am considering using Github with TestComplete and would like feedback as to whether this is a good or bad idea for my needs.


My current process:

  • We have one MainProjectSuite that is stored on a shared drive 
  • All 20+ of our test PC's open MainProjectSuite from the shared drive and run tests from it
  • Each of our 4 coders have their own Individual1ProjectSuite where they make any coding changes. 
  • I use WinMerge to compare the coding changes in Individual1ProjectSuite as compared to the MainProjectSuite.
  • If code looks fine, I use WinMerge to copy the updated coded into MainProjectSuite.
  • We don't use namemapping very much so it is not a concern.


What are the benefits of using Github as compared to our current process? I am mainly considering it as an easier way to review coding changes and better method to backup our main source code.

3 Replies

  • AlexKaras's avatar
    Champion Level 3



    > [...] better method to backup our main source code

    This is definitely the advantage of source control systems as they manage backups and change history.


    an easier way to review coding changes

    I would say that not always but as a rule. What personally I don't like in all modern non-locking source control systems is their automatic merge functionality. I treat it as a price that one must pay for the possibility to work on source code offline and in a distributed team. The problem is that merge not always works correctly.

    In order to minimize the chances of this I use the following approach:

    -- Check-in and commit to main branch often. You well may commit uncompleted and non-working code. Just make sure that this code will not prevent TestComplete from starting other tests due to some syntax errors and that this code is not called. If you have some syntax incompleteness (e.g. non-completed try/catch/finally structure), just comment it out, commit, uncomment and continue your work. Frequent commits minimize the chances of automatic merge problems;

    -- Pull from remote main branch often to minimize the chances that automatic merge will fail and corrupt your code. (Note, that corruption may occur not on the syntax level, but on logical one, when the syntax of your source will remain correct, but the logic will be corrupted.) As an additional means of prevention of this problem, I have an additional folder with a copy of my sources (CopyTo utility is great to synchronize between this folder and the one with actual project sources). I first pull into this copy folder and use CopyTo utility along with WinMerge to review what was changed. I then pull into my actual working folder if everything seems to be fine. Otherwise I have a chance to clarify/correct incorrect changes/merge problems before they are introduced in my working code.


    Yes, merge problems occur quite rare (in our test project, but quite often for developers), but my personal preference is to spend more time when pulling into my working test code than to spend time later trying to figure-out why tests stopped working.


    And another thing that I don't like in modern source control systems (SCS) is that they use project (SCS project, not test or development project) as a minimal atomic entity to operate with. I mean that if, for example, you decided to keep product code, test code and documentation into one SCS project, you will not be able to get, say, just a documentation to work with. You will have to get to your local drive all development and test sources even if you never need them. (For example, if you are a technical writer.)


    But in general, source control systems are a good means for versioned backup and more faster changes merge if used in a controlled manner.


  • rraghvani's avatar
    Champion Level 3

    Any form of software development work, it's vital to have source/version control to allow developers to store and manage their code.


    There's plenty of information with regards to source control,


    I use Azure DevOps Server formerly known as Team Foundation Server (TFS). I don't use the plugin that comes with TC, as it's sluggish and I don't like the UI. I use Visual Studio Team Explorer 2019, as it's quick and easy to use.

  • We did something similar before we switched to source control with GitHub and I can tell you, it is so much easier and you save a lot of time.


    If you've never dealt with source control before it can be a little intimidating but it's worth the effort.