You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, unit testing of repository_git is done by having the calls to git commands extracted into their own functions, and then having unit tests set these methods to test-specific methods on a per-test basis, as in:
where _git_remote_origin_upstream is a function defined in the unit test class.
I think it would be easier to write, understand and maintain the unit tests if we introduced a class whose purpose is to wrap various git commands. We would move all of the git static methods from repository_git.py into this new class. By default, a GitRepository object would be set up to hold an instance of the real GitWrapper class (this could be set up in the __init__ method of GitRepository. However, for unit testing, we could have a separate GitWrapperFake class, and we could set
This GitWrapperFake would have its own fake versions of all of the git commands, which return some specified value. They would all be set up with some default value (in case one isn't specified explicitly in a unit test), but they could all be configured. So we could have, for example, in a given test:
self._git_wrapper.set_git_remote_verbose("return value from git remote verbose")
By having the actual return strings in the given test, rather than needing to chase down the functions being used, I think the tests will be more maintainable.
The text was updated successfully, but these errors were encountered:
I'm hoping that through this and/or other mechanisms, we could move some of the repository_git unit tests to be at a slightly higher level - e.g., testing public functions rather than the internal _check_sync_logic. This would give me greater confidence that passing tests mean that things are working correctly at a higher level. But I haven't looked closely at doing that.
For functions that take an argument (e.g., the current def _git_revparse_commit(ref)): we could load up the fake with a dictionary of results, mapping a given input to a given output; if the input doesn't match one of the pre-loaded inputs, then it will raise an exception.
Currently, unit testing of
repository_git
is done by having the calls to git commands extracted into their own functions, and then having unit tests set these methods to test-specific methods on a per-test basis, as in:where
_git_remote_origin_upstream
is a function defined in the unit test class.I think it would be easier to write, understand and maintain the unit tests if we introduced a class whose purpose is to wrap various git commands. We would move all of the git static methods from
repository_git.py
into this new class. By default, a GitRepository object would be set up to hold an instance of the real GitWrapper class (this could be set up in the__init__
method of GitRepository. However, for unit testing, we could have a separate GitWrapperFake class, and we could setThis GitWrapperFake would have its own fake versions of all of the git commands, which return some specified value. They would all be set up with some default value (in case one isn't specified explicitly in a unit test), but they could all be configured. So we could have, for example, in a given test:
By having the actual return strings in the given test, rather than needing to chase down the functions being used, I think the tests will be more maintainable.
The text was updated successfully, but these errors were encountered: