One general thought I had FWIW: with some of these formatting things, it's hard to understand the test cases when the test cases are all generated by code as well... while I get the urge to not have too many raw fixtures in the codebase, it might be good to have at least some tests where there's a fixture or heredoc that'sjust the raw text of the rendered changelog / release notes / whatever. IMO that would make understanding and testing changes like that somewhat easier.

One general thought I had FWIW: with some of these formatting things, it's hard to understand the test cases when the test cases are all generated by code as well... while I get the urge to not have too many raw fixtures in the codebase, it might be good to have at least some tests where there's a fixture or heredoc that'sjust the raw text of the rendered changelog / release notes / whatever. IMO that would make understanding and testing changes like that somewhat easier.

That would be ideal but it is not really possible. That was my initial plan and implementation but it doesn't work out well with the varying HVCS links, always different git commit dates, the changing commit hashes with each build of the test repos. The pytest pretty diff plugin is supposed to show you the difference in your two logs but it doesn't work well with newline changes (I think its a bug). I don't like how much code I have to generate the changelog but it was the cleanest way to take a changelog spec and turn it into the correct content with variable HVCS and ever changing hashes. If you have a better solution that overcomes these obstacles then I'd be glad to switch.

Yeah, to replace it entirely probably wouldn’t make sense, especially since it’s already working, but maybe as an extra / separate and more limited test, not intended to cover all different scenarios.

The diffs make it easy to somewhat easy to see the difference between old and new (and did work in this case), but a little harder to see how the end result is supposed to look, or to adjust the test case before the code.