Are unit tests useful for real? [duplicate]

Question

Possible Duplicate:
Is Unit Testing worth the effort?

I know what is the purpose of unit tests generally speaking, but I found some things that bother me.

1) Purpose of tests early bug discovery. So, in some of later iterations, if I make some changes in code, automated test have to alarm me and tell me that I've screwed up some long ago forgotten piece of my software.

But, say that I have class A and say that is interact with some others class' instance, call it class B.

When one writes unit test for class A, he has to mock class B. So, in some future, if one makes some changes in class B, and that causes some bugs, they will reflect only in class B's unit test, not in A's ('cause A's test doesn't use real class B, but it's mock with fixed inputs and outputs). So, I can't see how could unit test do early notifying of made bugs that one isn't aware of? I'm aware of possible bugs in class that I'm changing, I do not need unit test for it, I need test to alarm me of consequences of my changes that makes bug in some "forgotten" class, and that isn't possible with unit tests. Or am I wrong?

2) When writing mocks and right expectations of calling methods, their inputs and returning values, one has to know how class-under-test is going to be implemented. And I think that that contradicts with test driven development. In TDD one writes tests first, and, driven by them, one writes a code. But I can't write right expectations (and tests in general) unless I write code that has to be tested. That contradicts with TDD, right?

Both of those problems could be solved if I used real objects instead of mocks. But that isn't unit testing then, right? In unit test class-under-test has to be isolated form the rest of the system, not using real classes but mocks.

I'm sure that I'm wrong somewhere, but I cannot find where. I've been reading and reading and I can't find what have I understood wrong.

Answer 1

I have just implemented TDD and unit testing for the first time. I think its great, and I have never used it in a contiguous integration environment, where I imagine its even more valuable.

My process:

1. Create the skeleton of class where business logic will go (be it a serivce layer, or domain object, etc).
2. Write the test, and define the method names and required functionaility in the test - which then prompts my ide to write the skelton method (a small but nice plus)
3. Then write the actual class methods being tested.
4. Run tests, debug.

I can now no longer write code without first writing its test, it really does aid develop. You catch bugs straight away, and it really helps you mentally order your code and development in a structured simple manner. And of course, any code that breaks existing functionality is caught straightaway.

I have not needed to use mock objects yet (using spring I can get away with calling service layer, and controller methods directly).

Answer 2

Strictly speaking, you spend more time in writing unit test rather than concentrating on the actual code.

there is no way you can achieve 100% code coverage. I do unit test my application, but I feel its not worth it. But not every one agrees with it.

If you change a piece of code, your unit test fail and figure out why its failing but for me its not worth it.

I am not big fan of Unit testing... You mock everything but mocking is big task..........

But now a days companies are trying for TDD approach.