AFAIK this is actually normal -- you learn the basics from tutorials, then the things that you need to make more complicated projects easier seem unnecessary, then you attempt a large project without them, and then you see why they're necessary.
Even something as fundamental as version control is, I think, passed up by a lot of beginning/intermediate programmers because "it's complicated" and "I don't need it now because I'm the only one working on this." But a mentor can help push you into that earlier and walk you through some of the more common stuff in a more accessible, interactive way than an article or a forum, which goes a long way.
A lot of room for disruption there I think if someone works out how to make version control fit better with ordinary people's view of the world (i.e. not git, svn etc). Versions in word are the closest I've seen to it but it really shouldn't be in one specific program but in the OS or a helper program.
Things like File History and Time Machine are nice, but don't really address this need.
"When you have a ham^H^H^HVCS, everything looks like a programming project".
I ask this as someone somewhere between "beginner" and "intermediate". I've used git on a bunch of projects, but normally get hung up with branches or with trying to undo changes. Even harder than version control, I think, is getting a lone beginner programmer to write tests. When I'm writing something, it's always tricky figuring out exactly what it is I should be testing. When time is a limiting factor, it's hard to get from "I know I should be doing this" to actually doing this.
When you are good enough to make your own projects work the way you want them to work, but not good enough to contribute to the open source projects you actually use, how do you break out of your bad habits that you know you will need to break when part of a team/large project?
If you don't have time to write tests then you've overscoped the features for the available time. Once you start treating testing as essential and budgeting a realistic amount of time to write test code (probably on the order of 1:1 feature code time:test code time) then you'll be able to get it done. Your total number of features will go down but quality will go up.
Sorry, that was a long way of pointing out that us novice programmers often don't have good methods of determining how long something should take because we've never done it before.
That is basically the core difficulty in software estimation: none of us have good methods for determining how long something should take because most of the time we haven't done it before. If it had been done before in a way we can reuse, we'd reuse it. The meat of most projects is always something that's in some way new, even when the new bit is integrating a bunch of pre-existing parts in a new way.
But there is no one true code to test ratio. If you're trying to become a better programmer be wary of dogma.
As posted here the other day, airbnb didn't have much testing until a year ago: http://nerds.airbnb.com/testing-at-airbnb/
I'm not saying either way is right or wrong, which is kind of my point.
You already have a hard problem on your hands, figuring out how to get something to work normally in this new environment. Don't compound that right off the bat by trying to learn a new testing system too. In addition, reality is the ultimate test. By getting it working normally first, you know that it actually works, so if you write a test against it, and the test fails, then the test is probably wrong.
Once you get good with it, you should be able to reverse it and go to a more TDD-like workflow - write tests and code first, then manually test, and have confidence that if the tests work, then the app will work for the users too.