That sounds more like unit tests than TDD. With TDD you should already know that you didn't break anything..
If you suck at writing code, then TDD should help you determine whether your sucky code produces the correct output for a given input; it is not however going to determine if you did that in the best possible way.
1) It should be a direct port of your specification. If you don't have a specification, you can't do TDD.
2) It should be written by someone who won't be writing the code. Or, at minimum, checked over by someone who won't be writing the code.
Writing tests after you've written code strongly encourages you to write implementation tests rather than specification tests. Both are important and useful, but for separate things (if you have to change your specification tests it's probably because you need to bump a minor or major version number for your software).
TDD, as outlined by the one who created the technique, as well as other big proponents such as Robert Martin, is done in tight 2 or 3 minute loops. As Kent Beck says, if you can't write your test in 5 minutes, you're doing too much.
(I mean, heck. Theoretically, Agile's "creators" designed it to be useful and helpful to developers. Cue sad trombone sound.)
Writing tests after code is completed, on the other hand, lends itself to reifying an implementation as "correct" and divergence from the implementation as being wrong. No bueno.
Well, if you suck at writing code, what guarantees do you have that the tests (which are also code you write) are even correct?