There are variations based on different coding styles and languages. However, regardless of the language you use, the biggest variation is you.
Robert Martin once said:
“As the tests get more specific, the code gets more generic.”
That made me think. More specific tests mean more test code. More generic production code means less code, so test/code ratios should rise as the code evolves.
But wait, that's not good either. In some particular cases, for example when you define a certain algorithm, you may have only 6-10 lines of code containing a couple of "if"s, a while and maybe 2-3 recursions. I can tell you, that code will have probably more 100 lines of test code.
In a real project, something bigger than just a few algorithms, the test/code ratio should be somewhere between 1:1 and 2:1. If it gets above 2:1, it's a smell that you have tests that should be refactored or deleted (or maybe code that is hard to test). You should always invest the same amount of care and refactoring in your tests as in your production code.
Any way, the best answer to your question maybe is "Cyclomatic Complexity". The higher the cyclomatic complexity of your method, the exponentially more test you have to write for it to cover all the cases.