Replies: 3 comments 5 replies
-
May I ask you: Why do you care about how the branch is named in the unit tests? Does it make any different if it is named master or main? From the configuration point of view both are included and treated the same. At the end everyone can use their own name and their own configuration in the unit tests. There is no need for unification IMO. |
Beta Was this translation helpful? Give feedback.
-
I didn't know if using "master" branch which should regex back to "main" config was the reason why I've really struggled to get a config that works in v6. When I started looking in to why I couldn't get a config that works the test code was extremely confusing. When you're talking about the config it does matter; so when you're passing around strings for both config ("main") and branch ("master" - which regexes back to the "main" config) it's not at all clear which to use in different scenarios. The proposal is intended to address that confusion in tests; it doesn't adapt the core functionality at all. In real use you can continue to use whatever names you like for config and for branches. I would propose that people writing tests have faced a similar challenge which ended up introducing "unknown", "other" and "custom" branch configuration keys. "Other" and "custom" I believe are exactly the same concept. "Unknown" is a different, test specific concept that's important to document clearly too. The "Custom" configuration key is retained; and can be used as many times with any names the tester wants - so long as there isn't a name conflict. Branch names remain as simple strings; but at least it's clear that it's a branch name, not a key to a configuration section. |
Beta Was this translation helpful? Give feedback.
-
Agreed, I'd only included it because it's present in the ConfigurationConstants on main. I did mark it obsolete too. Consider the following test: New to the codebase and wanting to replicate our usecase of the master branch default-mapping to the main configuration section
In both cases here we really are talking Actual.MainBranchName.
When working through tests I appreciated that some tests stepped outside the ConfigurationConstants.[ReservedName]Keys list, so wanted to show that I'd considered the need to keep everything unrestricted. None of this was intended to restrict the user, merely to clarify the intent of tests. I'm a big fan of the builder pattern and that's precisely where I would have proposed this to fit in. Maybe I've missed the {BranchNamePlaceholder} extraction. Ultimately it was merely a proposal borne out of my experience new to the code base. I appreciate the time you took to respond with a detailed reply. Most makes perfect sense - trying to use the builders in the unit tests to help me build up a configuration that actually works with unit tests proofing the theory is exactly where I have been headed. I've a related PR documenting 2 problems encountered where maybe I need to better understand; but also where there's inconsistent behaviour between the test fixture behaviour and the published dotnet-gitversion cli. More to come. Unknown - I'd not fully comprehended but I followed the explanation; I'll revisit, thanks. If you still don't see the value add and you want to keep strings for both branch and configuration key concepts, at the very least maybe you would consider, in tests, substituting some of the most confusing occurrences with named constants that would go a long way towards clarifying intent? After all the BranchConfigurationKey proposed wasn't much more than a type-safe wrapper around the ConfigurationConstants.[ReservedName]Keys anyhow. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
We still use master in almost all repos and I've been struggling to get a working config in v6 so I started looking at the test suite.
Quite soon I came across many "main" magic strings but also this:
GitVersion/src/GitVersion.Core.Tests/Helpers/TestBase.cs
Line 10 in f8a95ab
I reckoned if I changed that to master the generated test scenarios would behave accordingly, initializing and working with "master" instead of "main". But no, that constant is very sparingly used; many many magic strings all over and trying to make the tests behave quickly became a very noisy PR; so I just narrowed in on the absolute minimum so I could back this part out.
In the meantime I also encountered this (there's a whole suite of keys here):
GitVersion/src/GitVersion.Core/Configuration/ConfigurationConstants.cs
Line 31 in f8a95ab
The concept of BranchKey aligns to the standard sections the GitVersion.yml anticipates.
Throughout the test suite both "classes" of constant are passed around as strings and it gets really confusing very quickly which is correct and which won't work in various places in the code.
Could I suggest introducing a clear split, making the ConfigurationBranchKey a type safe concept that can be used to tidy up the string passing methods and parameters while leaving the Tester free to choose whatever actual branch names they want for commits to the repo.
Something like this perhaps (yes I've gone quite far down the rabbit hole already but because the magic strings are pervasive and widespread the PR will be big (~130 files) but very focused and imho fairly easy to delta). Test coverage is obviously good because this is all about tests, barely impacts the core functional code at all. High confidence that I can fit this in without breaking or significantly altering any existing tests (incl. TestCaseAttributes, Branches[]/SourceBranches, BranchMetaData, Custom, Unknown & Other).
Beta Was this translation helpful? Give feedback.
All reactions