2

I'm fairly new to git and I'm particularly interested in maintaining test cases for a project within its repository.

  1. This is for a small Bash side project and I have a few repositories. I would like to maintain the test cases within the same repo. How can I go about it? Do I maintain a long lived test branch where I merge in changes from the dev branch, run tests and then merge to the release branch? But doing so would force me to cherry-pick the feature/change from the test branch (assuming I also make changes while in the test branch) so that I avoid merging the test cases also. The branching models that I looked at talk about running test-suites on new commits to a dev branch as a CI/CD thing running separately. It makes sense for a large project and is convenient but not for a small one?

  2. Also, how would I advance the development of the test cases itself? Wouldn't maintaining separate repos for the test cases for each such project just bloat the number of repositories?

I was looking for best-practices where I had the following in mind: Maintain a release branch clean of any test artifact. Develop in a separate branch. Test to see if it is worthy to of release, if not make change, test again and merge only the change to the release branch. VonC's answer seems to suite this flow.

Machavity
  • 30,841
  • 27
  • 92
  • 100
htcm8
  • 111
  • 8
  • 3
    Why would you not keep the test cases in the same repository and the same branch? Why should the test cases be versions seperately from your code? – antlersoft Feb 04 '17 at 04:09
  • A pretty standard practice is to always require new features to be merged with tests. – Pockets Feb 04 '17 at 04:12
  • I do want the test cases to be in the same repository but perhaps not in the same branch because I don't want the test cases be present with "production ready code" when the release branch is checked out. – htcm8 Feb 04 '17 at 04:13
  • @antlersoft Well, it can be in the same branch. I was thinking more along the lines of maintaining test cases and the working code separate. – htcm8 Feb 04 '17 at 04:16
  • What is the concern with having the test cases present with your production code? Are they going to be deployed to hardware with **extremely** limited disk space to the point where the characters in your test cases are expensive? – BlackVegetable Feb 04 '17 at 04:23
  • :) No. It is just bash scripts for Ubuntu. Just wanted to keep the branches neat and organized. – htcm8 Feb 04 '17 at 04:27

1 Answers1

2

I do want the test cases to be in the same repository but perhaps not in the same branch.
Just wanted to keep the branches neat and organized

One trick is to:

  • keep your tests in a separate branch
  • refer to your test from the master branch as a submodule

See a full example in What's the easiest way to deploy a folder to a branch in git?

You commit your tests in the branch test, that you push.
Then you add that branch as a submodule in master:

git submodule add -b test git@github.com:user/repo.git test
git commit -m "added test as submodule"
git push

Your checked-out repo (in production) would by default have an empty test subfolder.
If you add (in development) a git submodule update --init, then the test subfolder would include tests content.

Each time you modify your tests, you add, commit and push from the submodule (which is set to push to the test branch).
Then go back to the parent folder (the one in master branch), add, commit and push the changed gitlink (special entry in the index representing the new SHA1 for the test submodule repo)

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thanks. Looks like I'll have to try out variations of the submodules and see which one works out best. I already have a few submodules that I thought are necessary as dependencies but now seem redundant. So, this should work out. – htcm8 Feb 04 '17 at 15:36