It's easy to write tests that have no value.
Especially if your employer mandates them. "You wanted tests. Here's your tests." If that's your criteria for tests then you're exactly right. The only thing they're doing is appeasing your clueless employer.
The ability to write useful tests is a hard won skill. It is not something that emerges easily when writing tests just because you were told to. You need to have a use for them in mind and do work that proves if they actually are useful.
It doesn't help that there are different philosophies about how it should be done. Some want every class isolated and all it's dependencies mocked. Others want only high level tests that show some behavior exists in support of some requirement.
I've come to the conclusion that, much like documentation, the most important thing to consider is a tests audience. A test can do a lot of damage if it was meant to prove a functions behavior that turns out to be replaceable with a completely different function with a different behavior that can't pass this old test. Such tests are fine in the hands of those that can see that and know to discard the test. But when others get hold of that test and wont let it go, it makes refactoring harder, not easier.
There are tests meant to satisfy your product owner. Tests meant to satisfy QA. Tests meant to teach new coders how the API works. Tests that enable refactoring without changing behavior meant to satisfy your peer reviewer. Tests meant to prove this implementation happens to behave the way you intend which should never be shown to another coder.
Why? Because while the test makes sense to you, it's weird and sure to confuse others. Tests that confuse people never die. Not every test is ready for public consumption.
Many argue about what to call these tests. Unit tests, integration tests, acceptance tests, end-to-end tests, automated tests, regression tests. These terms have become meaningless to me because I've seen them used to mean so many different things. I've learned to just keep asking what the term means in this particular shop until it’s clear. I want to know the point of each test. I don't blindly trust the names to tell me that anymore. Burned too many times. "It's a unit test" "Why?" "Because we run it with jUnit" "Ugg"
You're stuck with a testing requirement and no clear vision of the point of that requirement. I've been there. It's tough. If you have the time, try to identify the most useful thing you could do with testing for your employer. Put your focus there before trying to master everything.
TDD is an art. You really need to practice at home. TDD done halfway makes a nightmarish mess. You'll know when you have a handle on TDD when you do it, not because you're supposed to, but because it makes you faster. If it's slowing you down you're still not ready to do it at work.
Testing for planned refactoring is another story. Michael Feathers book Working Effectively with Legacy Code is a must read if you want to transform a code base with no tests into something else that has some tests that prove that you only changed what you meant to change.
Shops abound where the only point of tests is to have tests. Figure out something truly useful to do with them, or your shop will turn into yet another one. If so the tests will slow you down and cripple you.
Probably the best thing you could do is make the point of each test clear enough that those who come after you will have no doubt when it's time to delete the test. This is critical because when in doubt coders tend to drag old useless tests around.
If the test exists in support of some requirement, say that. If the test exists because some class exists, say that. If the test exists because some API exists, say that. This lets me know when to discard the test.
So when you ask, what's the point of unit tests, my answer is nothing until proven otherwise. If you can't figure it out then it needs to die. Clutter is not helpful.
Good tests show expected behavior. Good tests show intent. Good tests show what wasn't thought of. Good tests show how to express what wasn't thought of. Good tests are a handy way to peer review code. "Shouldn't your code do this? Cause it doesn't"
You know a test is good if, when it passes, it makes you confident. You feel no need to read the code it covers. You trust that code the way you trust your languages print command.
But just because a test passed does not mean it’s a good test. Be suspicious of tests you have only ever seen pass. Trust tests you’ve seen both pass and fail. That’s how you test the test.