For unit tests, you should know the input and expected output from the start. Really responsible devs write the unit tests first, because you should know what you're going to put in and what you'll get out before you start writing anything. If you find yourself making the same mistakes in your tests as you do your code, you might be trying to do too much logic in the test itself. Consider moving that logic to its own testable class, or doing a one-time generation of a static set of input/output values to test instead of making them on the fly.

How granular your tests should be is a matter of constant debate, but generally I believe that different file/class = different test. If I have utility method B that's called in method A, I generally test A in a way that ensures the function of B is done correctly instead of writing two different tests. If A relies on a method from another class, that gets mocked out and tested separately. If B's code is suitably complex to warrant an individual test, I'd consider moving to to its own class.

If you have a super simple method (e.g. an API endpoint method that only fetches data from another class), or something that talks with an external resource (filesystem, database, API, etc.) it's probably not worth writing a unit test for. Just make sure it's covered in an integration test.

Perhaps most importantly, if you're having a lot of trouble testing your code, think about if it's the tests or the code that is the problem. Are your classes too tightly coupled? Are your external access methods trying to perform complex logic with fetched data? Are you doing too much work in a single function? Look into some antipatterns for the language/framework you're using and make sure you're not falling into any pitfalls. Don't make your tests contort to fit your code, make your code easy to test.

If ever you feel lost, remember the words of the great Testivus.