A test that repeats the implementation can pass while proving very little. If the production code calculates a value and the test copies the same calculation to find the expected value, both can make the same mistake quite happily. I want the test to have a reason to disagree.
For me, that starts with the behaviour somebody depends on. Give it a concrete input and an expected outcome that follows from the requirement. If a bug involved the end of a date range, a repeated request or a missing record, keep that example. It explains why the test exists and gives a future change something meaningful to preserve.
That does not mean every line needs an elaborate test harness. Some changes are better checked by inspecting a render, running an existing integration check or verifying a real output. Building an abstraction purely so a trivial assignment can be tested often adds more code to maintain than the change itself. The check should fit the risk and the uncertainty.
I would rather review a small set of tests with clear failure meanings than a large set that mostly asserts its own setup. A useful failure says which promise broke. A green result should give us a specific reason to trust the behaviour, rather than just another number for a coverage report.