You should consider tests to be half of your work. If you deliver only the main code of a feature, you delivered 50% of your work.
Once you start thinking like that (which is good for you as a professional), you'll start forcing yourself to always write tests. The more tests you write, the faster you'll become at writing them. Basically, you start reaping the full benefits of testing when it becomes a habit in your daily routine.
That said, I know this is very hard and time consuming. My advice to you is to start breaking down your tasks into smaller tasks (if possible), and estimate your activities taking the tests into consideration (e.g. time*2). So, if you think you have a 2-day task at hand and cannot break it down to smaller tasks, make it a 4-day to account for testing.
This may seem like drastic at first, to spend 50% of your time on tests, but on the long run, the tests pay for themselves in terms of saved time. Also, it's the only human way to ensure your code actually works. The alternative is manually testing everything, everyday (needless to say, this is not likely to happen).
So, to summarize: my advice to you is always write tests (or at the very least, try really hard) even if it takes a long time. At first you'll feel like "wasting" a lot of time, but in time you'll come to appreciate the tests you wrote and realize they save more time than they cost to write. Of course you have to get good at it. Remember: test code should be cared for as carefully as production code. They are both EQUALLY important parts of the feature you are delivering.