Same. I know Jenk (not try to speak for him) tries not to use any issue tracker, he uses incomplete test cases to "track" an issue, or a failing test to "track" a bug. I do use an issue tracker and sometimes I will put the bug number in a comment, but typically only if the test isn't obvious. The "bug" was more like a missing feature, I'll try to make it blend in with my other tests (no comment). If its hard to understand why that test is there, I'll put the comment so I don't decide to remove the test later when I don't recognize it.
Its almost always better to use an assertion message / good method name than a comment. Would you rather get an error about "assertion failed on line X"? Or an assertion that describes in plain English what broke? The goal is to have your assertion messages be so crystal clear on their own that you'll never need to use a debugger while refactoring code, when you edit some code and it breaks a behavior it should be crystal clear what you edited, what it broke, why it broke it, etc.. All the whos/whats/whens/ and wheres should be obvious from the test runner output alone, without requiring a developer to necessarily read the test or production code.
"Anything that is important to be in a test should be in the test. If its not important to be in a test, its important thats its not in the test" - http://www.amazon.com/xUnit-Test-Patter ... 0131495054
^ Golden rule to live by