[lazylester]

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]

This 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]

I 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]

Typically 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.