1. Unit Testing is useful ONLY for complex API method/function, which should not change too often and too frequently; 2. Ideally, you should only test API not

1. Unit Testing is useful ONLY for complex API method/function, which should not change too often and too frequently; 2. Ideally, you should only test API not API's implementation but most of the mock framework will tie your test code directly against your API implementation. Once your API implementation changed, your test code fails, you have to rewrite test code, which is waste of time. Someone may argue that it because you write bad test code; Talking is easier than doing; So, usually, I prefer to doing the functional integration test than the unit test, which is productive for me. (I know people will throw out thousands of reasons about the benefit of unit test and "correct" way of writing unit test.) Anyway, I will avoid unit test as possible as I can and ONLY do my designed integration test, which works for me. 3. And writing unit test for code coverage is stupid; Some manager even brag about the unit test coverage, which is totally a false confidence about the quality of the code underline; This is even stupid; 4. Writing unit test for those requirement-always-change area is waste of time; 5. TDD is a BIGGEST JOKE, which weights too much on writing auto testable code over writing working functional productive code;