In our product group we target 50-70% code coverage from unit tests and 90%+ coverage from unit tests and test automation combined. Typical time budgeted on writing unit tests is about 1 day for every feature that takes 3-4 days of heads down coding. But that can vary with a lot of factors.
99% code coverage is great. Unit tests are great. But 99% code coverage from unit testing alone? I find that hard to believe that you can get that much coverage from unit testing alone.
For the case where you spent 3 days writing tests for a class that otherwise took 1 day to implement. You didn't elaborate as to why it took this long or share any code. From speculation, I am guessing you weren't really writing a true unit test for your class, but were actually writing test automation. And there's actually nothing wrong with that - as long as your recognize the difference between the two different types of tests.
But you said the three days of test writing was only for a single class. Perhaps the class itself was not designed for unit testing. Does the class implement UI? Networking? File I/O? If so, you might have ended up writing more code to test the Java runtime than your business logic that interacts with the runtime.
TDD gets you thinking in terms of interfaces and interfaces to dependencies. That single class that implements UI, networking, and file/io for a single feature might be better served split into multiple classes - one for networking, one for file/io, and the UI broken into a model-viewer-controller design. Then you can implement appropriate tests for each with simple mock objects for the dependencies. Of course, all of this takes up more time. So rather than 1 day to code and 3 days to write tests, this type of design may require 3 days of coding and 1 day of writing tests. But the code will be far better maintainable and reusable.