Behavior-Driven Development to the Rescue?

I've been trying to wrap my head around how I can increase LinFu's test coverage rate for over a week now, and I have to admit that doing DDT testing (aka TDD in reverse, or post-hoc unit testing) is much more difficult than its TDD counterpart.

In contrast, TDD seems to apply a bottom-up approach to ensure that each component is functioning, and in LinFu's case, I'm going to need a top-down testing approach to ensure that all of LinFu's features work as advertised. My intent is to write each test as a specification for LinFu's behavior, and each one of these tests will ensure that LinFu behaves according to its specification.

It's by no means perfect, but it's the only practical solution that I can apply to the existing code base without having to rewrite it. At best, it seems like an ugly hack since I'll be effectively doing black box testing against LinFu instead of getting the 100% test coverage.

The other alternative, of course, is that I can do a complete rewrite of LinFu (presumably version 2.0) from scratch. (It's not a pretty option, but then again, it's no better than having to do post-hoc unit testing).

So here is my question for the developer community at large: Which option should I take, and why? If I do LinFu v2.0 with a 100% test coverage rate, will that up the adoption rate, or will LinFu v1.0 with specification tests added be sufficient enough to fix the test coverage problems?