unit testing - How to approach unittesting and TDD (using python + nose) -

i have been trying hang of tdd , unit testing (in python, using nose) , there few basic concepts i'm stuck on. i've read lot on subject nothing seems address issues - because they're basic they're assumed understood.

1. the idea of tdd unit tests written before code test. unit test should test small portions of code (e.g. functions) which, purposes of test, self-contained , isolated. however, seems me highly dependent on implementation. during implementation, or during later bugfix may become necessary abstract of code new function. should go through tests , mock out function keep them isolated? surely in doing there danger of introducing new bugs tests, , tests no longer test same situation?

2. from limited experience in writing unit tests, appears isolating function results in test longer , more complicated code testing. if test fails tells there either bug in code or in test, not obvious which. not isolating may mean shorter , easier read test, not unit test...

3. often, once isolated, unit tests seem merely repeating function. e.g. if there simple function adds 2 numbers, test assert add(a, b) == + b. since implementation return + b, what's point in test? far more useful test see how function works within system, goes against unit testing because no longer isolated.

4. my conclusion unit tests in situations, not everywhere , system tests more useful. approach implies write system tests first, then, if fail, isolate portions of system unit tests pinpoint failure. problem this, obviously, not easy test corner cases. means development not test driven, unit tests written needed.

so basic questions are:

1. should unit tests used everywhere, small , simple function?
2. how 1 deal changing implementations? i.e. should implementation of tests change continuously too, , doesn't reduce usefulness?
3. what should done when test gets more complicated code testing?
4. is best start unit tests, or better start system tests, @ start of development easier write?

regarding conclusion first: both unit tests , system tests (integration tests) both have use, , in opinion useful. during development find easier start unit tests, testing legacy code find approach start integration tests easier. don't think there's right or wrong way of doing this, goal make safetynet allows write solid , tested code, not method itself.

1. i find useful think each function api in context. unit test testing api, not implementation. if implementation changes, test should remain same, safety net allows refactor code confidence. if refactoring means taking part of implementation out new function, it's ok keep test without stubbing or mocking part refactored out. want new set of tests new function however.
2. unit tests not holy grail! test code should simple in opinion, , should little reason test code fail. if test becomes more complex function tests, means need refactor code differently. example own past: had code took input , produced output stored xml. parsing xml verifying output correct caused lot of complexity in tests. realizing xml-representation not point, able refactor code test output without messing details of xml.
3. some functions trivial separate test them adds no value. in example you're not testing code, '+' operator in language works expected. should tested language implementer, not you. function won't need more complex before adding test worthwhile.

in short, think observations relevant , point towards pragmatic approach testing. following rigorous definition closely in way, though definitions may necessary purpose of having way communicate ideas convey. said, goal not method, result; testing have confidence in code.