Hi @cruelsmith - this is a lot of work you've put in, thanks! Note that there has been some work on #162 already but I had not yet created a PR.

I am a bit confused about the purpose of the spec test changes, and how it relates to moving to Hiera from the params pattern. Should this be a separate PR? Note #183 - which I've just rebased on to the current main and pushed and intend to merge shortly, which may significantly change your approach here, or perhaps the changes would not be required?

The spec fix could be separate PR but the hiera migration with 💯 % kill the current spec test setup.
Since this

In my 👀 #191 was completely unneeded and i prefer package { $package_name: } over package { 'fix_name': name => $package_name }

Also #183 is not fixed at all. You guys still just test against your variable overrides you do via

Re #191 - this is really off topic here so any further comments on #191 being a good idea or not, let's put that in the #191 discussion. My comment however is that the change in #191 allows us to much more easily include multiple OSes in specs, as different OSes have different package names, and store freeradius config in different places. This way, the vast majority of the spec can reference consistent names, and per-OS filenames, package names, etc. can be tested if required, without requiring the specs to be defined per-OS.

Yes - the redhat_params_class is unusual. It was an interim step, before #191 was done. The intent was to be pragmatic and get tests working "enough" by forcing every OS to have redhat-like values - and it did, and it allowed us to have useful tests.

Now that #191 is done, we can update the specs to take advantage of this. I will put together a PR.