Depends on the type of test. If you track acceptance tests (like Gherkin or FitNesse) it’s a tight tie to user value. You still have to be careful, because just because it’s user facing doesn’t mean it’s user-valuable, but it’s at the level of weaselness that UVIs are.
Also, getting those acceptance tests complete requires some discipline, since they’re only examples you have to ensure your code handles all cases, not just the example. They also don’t protect against any but the simplest of bugs.
One nice thing about doing scenario based testing is you don’t need to automate them, but it gives a relatively clear picture of partial value to users as you progress and mark them off as working. It seems to be a good fit, but you know your context better than I do, and there are no testing best practices, only good practices in context 
.
I agree that beeminding programmer level tests (dots from the test runner) would be about like beeminding time or other “input” activities.