4 ms·
Personally I use TDD (or more precisely BDD) for this purpose. If I leave the project overnight, or for a week or a month, I can come back to it, run the tests,
by lazylester 10y ago
Personally I use TDD (or more precisely BDD) for this purpose. If I leave the project overnight, or for a week or a month, I can come back to it, run the tests, and the failing and/or pending tests tell me what I was doing when I last worked on it.
So I always leave an in-process development project with failing tests. If they're all green, I don't know what to do next!
- daily-q 10y agoThis method also works for me. Usually the failing test left behind is something in the same space of where work needs to be done, but I like to keep the failing code trivial so that I can ramp up. 'Works great. A TODO file can also be used to accomplish this if TDD isn't your thing.
- nerdy 10y agoI think a TODO is preferable even if you practice TDD. Failing tests used as a "start here" are to-dos in this instance and are indistinguishable from legitimate currently-implemented feature tests if you've been away long enough. I don't think it's good to assume it's okay to delete failing tests when returning to a project with new goals or when a bug needs fixing. For me, it's important to return to a project, run tests and have them all come back green. Then if I break something, I know it broke and isn't just an artifact from my pseudo to-dos. Along those lines... I always try to run tests, check code coverage (including via mutation testing), and commit changes before calling it a day.
- lazylester 10y agoTypically the error messages that I include for my "this is where I left off" or "still to do" tests are like "page not yet implemented" or "haven't figured out the bug". No definitely don't delete failing tests! Make them pass.