I'm not sure for you, but for me Automatic Tests (Unit tests if possible) are a good way of discovering how the code works, and knowing that it doesn't work as expected.
Automatic Tests replaces debugging, changing a memory-backed developer-checked knowledge and verification, to a file-backed explicitely-checked one.
When coming back to your work later on, you will be at the same point after a few seconds executing your tests, instead of trying to retrieve your context from old memories and replaying a long debug sequence (these last two activities may require written communication anyway as memory might not suffice ; then Automatic Tests would have no overhead).
I know, some projects are not easily testable automatically. We use TDD to solve that problem, gaining also many other advantages ....
If you already write some automatic tests, the same tests you write automatically track what you are thinking and verifying, so you probably need nothing else. When you finally found your bug, you can keep your test sequence ... or refactor it ;-)
Edit after comment :
Testing how a library works ! I call that learning tests.
Good that you do them :
- they let you know exactly how the library is working.
- they document that knowledge, for you later or for your team members
- they may document the uses of that library, how it is used in your project
(in my Aeronautics experiences, the company policy mandated that each external code is controlled, knowing precisely what features are used, and documenting what would be the effect on our software if the library would stop working !)
- they serve as a non-regression test when you upgrade your library