Test what lets you feel confident in your software. That's all the tests do, ensure that what you wrote does what you think it does (especially as you change things).
Some of this is personality. You could write 0 test and be 99% confident, and of course you'll be surprised sometime. You could write a lot of tests and be 10% confident, because you're just a worrier.
Personally, I'd suggest writing tests for your main functionality and flows. Logging in, sending data to the database, running an algorithm, receiving an event from somewhere, etc. These can just be the success cases for now, but when you run your tests you'll know the main pieces of your software will work.
And make sure they work together - have some tests that interact with more than one component. I know that's not a "true unit test" and I won't get into the choices between integration tests and unit tests, but if you test everything in a vacuum, you will have unfounded confidence that all the pieces work together.
Again, the point of running an automated test suite is that: if the tests pass, you know your software will work (at least as well as the tests are written, so you can always add more tests as corner cases come up).
In My Opinion: I'd suggest testing your system from "the outside". Are you writing a REST server? Write your tests as HTTP requests to ensure the correct data goes in, and the correct data comes back. I'd use a real database rather than mocking everything because sometimes persistence or queries don't work exactly like you code them. You'll be more confident that the outside "user" of your software will get the data you'd expect, and your software performs as intended.
