HN user
It doesn't matter. It is most likely a pretext for upcoming actions mostly likely executed via yet another retarded executive order. The guy that posted this looks like he's drowned himself in the MAGA Koolaid.
Technical debt is an explicit choice to optimise for speed of delivery at the cost of having to do more work later to bring the delivered code up to the usual expectations of code/features in the system. Ideally the choice to take on that technical debt comes with an agreement of when the debt will be paid down and an understanding of the additional work that will be required because of the shortcut being taken now.
It is not technical debt if there is no explicit decision, or it is the gradual and continuous bitrot that all codebases suffer. I usually refer to this as cruft and while good design and writing code to optimise for readability / understandability reduce the rate that cruft accumulates, it cannot be stopped due to the nature of software. The best practice I have found to fight cruft is many small refactorings and cleanups as part of every piece of work I deliver. This strategy is outlined in https://ronjeffries.com/xprog/articles/refactoring-not-on-th....
Looks like a similar concept to https://github.com/machine/machine.specifications which I used many years ago to try and achieve BDD style unit testing.
One point to note from your introduction was the following statement: I often find unit tests are hard to read, and especially harder to quickly identify what are the important pieces, or even what the test is testing about
Have you considered pairing with others in your team or using group code reviews to see if there is a style or understanding gap? This may be far more effective than trying to get people to use a novel unit testing framework with little or no real longevity.
The most important lessons in coding have little to do with coding and a lot to do with people - code is written for people not the computer.
The more you know the more you will come to understand you don't know much; that is both good and bad (Dunning Kruger vs Imposter Syndrome).
Every time you think you are the best in the room, look around and ask yourself are you overestimating your knowledge. If you are still the best in the room, maybe it is time to find a room with smarter people.
Not every solution requires code / technology.
The best code is easy to read and even easier to delete.
Give your code to the most junior member of your team - if they struggle with it you need to make it simpler.
There are many many lessons like these around - the single most important one - always be open to new ideas no matter how much they oppose your current beliefs; strong opinions, weakly held.