iOS Writing Unit Tests. Forcing me to make more properties and public methods?

Hi there,
I've recently been exposed to the wonderful world of TDD and writing UnitTests in my day-job. At an intellectual level I accept the fact that this is a good way to go about things and should make the code a lot easier to maintain. At an emotional level I am not yet in love, though.

I have therefore started my own private project thinking it would ease me into the right way of thinking without having to both write tests and refactor someone else's code at the same time.

One thing that kind of bothers me is frankly the detail-level of the tests. What I find is that if I really want to keep things as maintenance free as possible I should write at least one test for any method that changes any value that will be in any other method or class.

The problem with this approach is that it seems to force me to make more or less any method public, and any value into a property. If I for instance have a class that has the responsibility of setting up a dictionary, I really don't want to make properties out of every single object in that dictionary. But, if I am to write tests that makes it obvious where code is broken, it seems I need to this as well as making a lot of otherwise private methods public.

The alternative seem to be to write a lot of tests towards one method and adding a (small] level of complexity when needing to find the culprit for broken code down the road...

Any thoughts on this?

After some more googling I seem to have found an answer to a huge part of my question:

Adding category methods matching the methods I want to run tests against seems to to the trick. This way I avoid having to make my methods public and can still write tests to my heart's desire.