Does worth testing simple details?
Maybe?
I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a given level of confidence -- Kent Beck, 2008
Within the context of Test Driven Development, "programmer tests" are motivated by analysis and design, not by validation (see Aim, Fire -- Beck, 2001).
For code that is "so simple that there are obviously no deficiencies", creating a bunch of tests is an investment that you may want to defer until you discover that further complexity is required.
If you are aware of the gap between decision and feedback during programming, and you are using appropriate techniques to control that gap, then you are doing TDD "the right way", even if the appropriate technique that you use isn't an automated check. (Note: this is from Test Driven Development by Example, the same source that says we should write a failing automated test before we write any code. Mixed signals are mixed.)
If you are considering tests for validation, then the considerations are a little different. Ultimately, we (not the authors of the form library or the framework) are answerable to our customers/goal donor/gold owner. So we need to understand what risks we are trying to mitigate, what mitigation strategies are available, and which of those strategies offers the best combination of trade offs.