# Meta-feature request: don't put yourself on the hook for any more big features **URL:** \ **Category:** Bugabee\ **Created:** [November 1, 2014, 1:31pm UTC](https://forum.beeminder.com/t/meta-feature-request-dont-put-yourself-on-the-hook-for-any-more-big-features/198 "2014-11-01T13:31:44Z")\ **Posts on this page:** 1\ **Showing post:** 6
**Author:** ![thunderbolt16](https://avatars.discourse-cdn.com/v4/letter/t/919ad9/32.png) [@thunderbolt16](https://forum.beeminder.com/u/thunderbolt16)\ **Post date:** [November 2, 2014, 4:45am UTC](https://forum.beeminder.com/t/meta-feature-request-dont-put-yourself-on-the-hook-for-any-more-big-features/198/6 "2014-11-02T04:45:25Z")
Depends on the type of test. If you track acceptance tests (like [Gherkin](https://github.com/cucumber/cucumber/wiki/Gherkin) or [FitNesse](http://www.fitnesse.org/FitNesse.UserGuide.TwoMinuteExample)) 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. --- _[View the full topic](https://forum.beeminder.com/t/meta-feature-request-dont-put-yourself-on-the-hook-for-any-more-big-features/198)._