it is the duty of the configuration helper to build a map
providing the configuration. Having facilites to use the
ConfigurationHelper as some kind of configuration registry
makes life more complicated.
there is only one test class making use of it left. This test class is the
GitUtilsTest itself.
Hence moving this member downwards in the test class hierarchy into GitUtilsTest.
I doubt it makes sense to make use of a generic git utils mock somewhere else since this basically
means to test the GitUtils class in the conxtext of other examinees. For that there is no need.
The GitUtils class should be tested by the corresponding test class, but not in a transive manner
by other tests. For all other tests a specific git utils mock should be provided mocking the corresponding
method class. This is already the case today, otherwise we would have more test classes making use
of the generic git utils mock.
- In ArtifactSetVersionTest the method was declared,
but not used at all.
- In MtaUtilsTest there was a particular Object created
for the sole purpose of serving as script.
For that we have the nullScript.
- In DockerArtifactVersioningTest 'this' was configured to
serve as script. There is basically no reason why the
instance of the JUnitTest should serve as script.
Instead we have the nullScript for that purpose.
GStrings might be handed over e.g. via signature to steps.
GStrings in configuration makes it harder to deal with configurations.
E.g.
```if(param == 'a' || param == 'b')``` returns true if a is a GString representing 'a'
but
```if(param in ['a', 'b'])``` returns false.
It would be possible not to use the ```in``` notation in our code. But this
increases readability.
GString are not significant and can be replaced by the corresponding java.lang.String
representation without loss of information. Hence it is justified IMO to ensure
there are no GStrings contained in the configuration map.
if we don't mock the GitUtils here changes inside GitUtils affecting the git commands
issued at the command line requires changes here. In fact we have to react on
implementation details of the GitUtils here. It is better to be independent from that
implementation details here since this leads to more focused and smaller commits.
Up to now we had two constructors, one with a Script and the other one with a map holding some defaults.
In case the constructor with the map was called the step name was uninitialized
In order to ensure all actions applied by 'use()' are also
applied before returning a single configuration values.
Possible optimization: introduce a flag indicating that 'use' has
been called (not implemented for now).
The other merge method called in the body of that method here does not exist.
So any call to this method would end up in some method not found exception or similar.
