If it's truly trivial code, you should be able to test it trivially, so I'm a little unsure of why this becomes a make-or-break issue for some people. Pretty sure more time and energy is wasted determining if code is trivial and needs to be tested versus just testing the damned thing ;-).
Trivial tests may be trivial, but they are numerous: their need grows exponentially with code size. And they generate almost all the false positives you will get.
The DirectX12 api is non-trivial code; their testing has little in common with TDD.
Maybe, but I'd wager on the whole that you probably don't. Your surface API should be the same, and you shouldn't be testing internal implementation anyway. If you write clear and consistent interfaces, then forgetting a requirement will mean adding a test – not rewriting them.
Why not? When my big black box stops giving me the expected answers I want to know exactly which cog inside that box that broke.
I agree that there's nothing worse than a test that says "your stuff broke" and provides no additional information why. But there's a balance between that, and testing the internals of an implementation.
What kind of test could you possibly write that would break because of this? Something that measures time or memory usage, or uses reflection?
If you have clearly defined interfaces between significant internal components (which you should), why not test that they do what you ask? Public vs. internal is often more about what is exactly the client of the code, not the code's function or structure itself.
Unit tests are great, but they should still be testing at the boundary of code modules – if changing the internal implementation of that module breaks a test, it probably isn't testing at the correct level.
I think testing trivial code is a waste of time and does nothing but improve coverage numbers.
When you think about a non-trivial problem to write tests, you don't always know what the final code will look like. Maybe you forget an edge case or some small detail in the requirements that will cause you to restructure the code and approach the problem in a different way. In which case, you now need to re-write your tests. You might as well just write tests around the final version.