koobas.hobune.stream
Do I have to commit the UnityTestTools to the repo?
Hello all, new to Unity, first post.
QUESTION (Short version)
Q: Do I have to commit the UnityTestTools to my repo? (using GIT btw).
CONTEXT
Team
We are an indie team of 10 people (of which 4 coders, 2 graphics, 1 music, 2 marketing, 1 automation-test QA), remotely located.
We built the team 2 weeks ago, have explored Unity, decided that unity shall be our devel framework, and finally we did an internal silly tic-tac-toe internal for us to check the workflow.
Now we want to start developing our 1st game. Clean code. Clean repo.
Using GIT for version control.
We configured Unity to write all forced in "text" and visible metas.
We are using Unity5 free edition.
Coding
Up to now, I've managed to create a MVC schema. MonoBehvaiour acts as the "Controller" and then we have "non-dependant classes" that act as the "Model" of our game. The controller calls methods of this model. The model throws events to notify the changes in its state.
We want to "unit-test" the model.
Assets
Yesterday I discovered the UnityTestTools
This is the only downloaded asset, the rest of the assets are made by us.
The wonderings presented by this question may happen again if we download other assets.
QUESTIONS (Long version)
The same way in PHP you may use "composer" to handle "dependencies" so if you need a library you do not commit it inside your project, you just commit a text file saying "I want this library, this specific version", there are our questions/wonderings:
Q1) Do I have to commit all the UnityTestTools in my repo? It is 10 Megas - may seem an overkill or not, as it carries "examples" and I don't know how to filter what is needed and what not - but this might happen with another asset that is 500 Megas for example. Committing downloadable assets seems anti-pattern. Do I have to commit?
Q2) Or it is better that I don't, and have all the members in the team to manually download UnityTestTools?
Q3) If they delete that repo and download it again, the UnityTestTools seem to be kept local to the project, then a new download is imposed if it's not kept in the repo? Or Unity may store "local in your computer" things like "the testing library" you are likely going to use in several projects?
Q4) Case one thinks "maybe each project needs its own version of libraries, nothing global" then, committing them to the project still seems overkill... is there any standard of "config file" that I can place and then once the "git repo" is cloned, run some kind of "dependency installer" or so (much like "composer" is to "PHP"?
I've seeked for information, but I'm still confused on this. I've seen it exists something like an "asset manager" but I'm not sure if this is what I need. Any pointer to documentation I must read will be highly appreciated.
Thanks!
You may want to only push relevant files. For instance, pushing the whole project things on Github is a massive pain as the csproj and likes are always conflicting. In our case we only push the Assets folder. Each user create a new project and clone the repo into a Assets folder. Only you need to add manually the tag and layers but the process is somehow more simple.
You should also do the same with your TestTool. There is no reason why the test asset should be pushed since anyone can dl it from AssetStore. Only the relevant settings could be pushed and pulled.
Commit a version of Unity Test Tools to your repo and make the whole team use it. It's safer to stick to one version across the whole development and have full control on updating to new versions. Besides, there is no Asset Store dependancy manager as far as I know.
You should also remove the examples before commit the package - you simply don't need them and they take extra space.
Woud it be possible to programmatically retrieve a specific version? I mean: Say I use "asset ABC version 1", say they update it to "version 2". When version 2 is posted, is it possible to "force" to download version 1?
Asset Store doesn't support getting previous version of the assets and doesn't have an API for it either. You can get older version from the bitbucket repo (https://bitbucket.org/Unity-Technologies/unitytesttools). All the release version are tagged.
Does it have the very same effect installing from AssetStore than cloning/checking-out from the repo? If there isn't any significative difference, then the answer to my question could be just to write a script (let's call it "composer.cs") that gets the right version of the UnityTestTools from the original repo, so the only committed things to the project are the script ("composer.cs") and its configuration (for instance "composer.json"). Is this correct?
It's the same code that is published to the Asset Store.
What you're saying would work but I don't understand why you wouldn't just commit the code to your repo. I understand that having a package manager is a nice thing but writing your own code for that seem unnecessary for me.
