Unit testing is checking that function returns the correct data in different scenarios. This can be easily done with unit testing functions for your language.
For example C preprocessor macros I use for unit testing.
#define equal(a,b) printf("%X == %X = %s\n", a, b, (a == b) ? "true" : "false");
#define diff(a,b) printf("%X != %X = %s\n", a, b, (a != b) ? "true" : "false");
On a technical level, if your language doesn't support things like inversion of control (in one form or another) and reflection/proxying (or a dynamic runtime), it's going to be an uphill battle to write effective, non-brittle unit tests. Therefore, maybe end-to-end integration tests might be a better fit (for which, I'm no expert).
Similar. Don't look for a "plug-and-chug" formula. Understand what went wrong and why. When you look at your own work, those lessons will be floating around in your subconscious and sometimes surface into conscious concerns.
Have a deep-seated concern about "getting it right". If you don't have this, you won't "make" yourself do the rest. You need the interest in getting things right, as a precursor.
(I've seen a lot of QA that reduces to "pushing buttons in return for a paycheck". This level of involvement won't get you too far -- although it is, or was a few years ago, quite prevalent.)