Return to Answer

In many ways I agree with your team.

1. Most unit tests are questionable in value. Since the vast majority of tests seem to be too simple.

2. It is much harder to write good testable code than just working code. There's a large percentage of the developer community that believes in just get it to work, versus code/design quality in itself. And an even larger percentage who don't even know what quality code is.

3. It can take much longer to write the unit test code than the actual code itself.

4. Figuring out how to adequately test the more complicated code (ie. the stuff you really are interested in thoroughly testing) is beyond many developers capabilities.

5. Maintaining unit tests takes too much time. Small changes can have big ripple effects. The main goal of automated unit tests is to find out if changes broke the code. However, 99% of the time what ends up breaking are the tests and not the code.

With all the above problems, there still isn't a better way to be able to make code changes and have some level of confidence that something didn't unexpectantly break than automating your tests.

Some of the above can be alleviated to some degree by not going by the textbook of unit testing.

EDIT: Instead, many types of designs/applications are better tested by automating tests at the module/package level. In my experience, most coding errors are not because the code in a class was coded incorrectly but because the coder didn't understand how their class was supposed to work with other classes. I have seen a lot of bang for the buck in this type of testing. But once again, these tests are harder to write than unit (class level) tests.

It really boils down to whether the developers believe in the process or not. If they do, then they'll write good unit tests, find errors early and be proponents. If they don't, then their unit tests will be by and large useless and won't find any errors and their theory of unit tests being useless will be proven true (in their minds).

Bottom line is that I've never seen the full blown automated unit testing approach work for more than a couple months myself, but the idea of automated unit tests still persists but we are selective in what really needs testing. This approach tends to have far less critics and is more accepted by all the developers rather than just a few.

In many ways I agree with your team.

1. Most unit tests are questionable in value. Since the vast majority of tests seem to be too simple.

2. It is much harder to write good testable code than just working code. There's a large percentage of the developer community that believes in just get it to work, versus code/design quality in itself. And an even larger percentage who don't even know what quality code is.

3. It can take much longer to write the unit test code than the actual code itself.

4. Figuring out how to adequately test the more complicated code (ie. the stuff you really are interested in thoroughly testing) is beyond many developers capabilities.

5. Maintaining unit tests takes too much time. Small changes can have big ripple effects. The main goal of automated unit tests is to find out if changes broke the code. However, 99% of the time what ends up breaking are the tests and not the code.

With all the above problems, there still isn't a better way to be able to make code changes and have some level of confidence that something didn't unexpectantly break than automating your tests.

Some of the above can be alleviated to some degree by not going by the textbook of unit testing.

Many types of designs/applications are better tested by automating tests at the module/package level. In my experience, most coding errors are not because the code in a class was coded incorrectly but because the coder didn't understand how their class was supposed to work with other classes. I have seen a lot of bang for the buck in this type of testing. But once again, these tests are harder to write than unit (class level) tests.

It really boils down to whether the developers believe in the process or not. If they do, then they'll write good unit tests, find errors early and be proponents. If they don't, then their unit tests will be by and large useless and won't find any errors and their theory of unit tests being useless will be proven true (in their minds).

Bottom line is that I've never seen the full blown automated unit testing approach work for more than a couple months myself, but the idea of automated unit tests still persists although we are selective in what really needs testing. This approach tends to have far less critics and is more accepted by all the developers rather than just a few.

In many ways I agree with your team.

1. Most unit tests are questionable in value. Since the vast majority of tests seem to be too simple.

2. It is much harder to write good testable code than just working code. There's a large percentage of the developer community that believes in just get it to work, versus code/design quality in itself. And an even larger percentage who don't even know what quality code is.

3. It can take much longer to write the unit test code than the actual code itself.

4. Figuring out how to adequately test the more complicated code (ie. the stuff you really are interested in thoroughly testing) is beyond many developers capabilities.

5. Maintaining unit tests takes too much time. Small changes can have big ripple effects. The main goal of automated unit tests is to find out if changes broke the code. However, 99% of the time what ends up breaking are the tests and not the code.

With all the above problems, there still isn't a better way to be able to make code changes and have some level of confidence that something didn't unexpectantly break than automating your tests.

Some of the above can be alleviated to some degree by not going by the textbook of unit testing.

EDIT: Instead, many types of designs/applications are better tested by automating tests at the module/package level. In my experience, most coding errors are not because the code in a class was coded incorrectly but because the coder didn't understand how their class was supposed to work with other classes. I have seen a lot of bang for the buck in this type of testing. But once again, these tests are harder to write than unit (class level) tests.

It really boils down to whether the developers believe in the process or not. If they do, then they'll write good unit tests, find errors early and be proponents. If they don't, then their unit tests will be by and large useless and won't find any errors and their theory of unit tests being useless will be proven true (in their minds).

Bottom line is that I've never seen the full blown automated unit testing approach work for more than a couple months myself, but the idea of automated unit tests still persists but we are selective in what really needs testing. This approach tends to have far less critics and is more accepted by all the developers rather than just a few.

In many ways I agree with your team.

1. Most unit tests are questionable in value. Since the vast majority of tests seem to be too simple.

2. It is much harder to write good testable code than just working code. There's a large percentage of the developer community that believes in just get it to work, versus code/design quality in itself. And an even larger percentage who don't even know what quality code is.

3. It can take much longer to write the unit test code than the actual code itself.

4. Figuring out how to adequately test the more complicated code (ie. the stuff you really are interested in thoroughly testing) is beyond many developers capabilities.

5. Maintaining unit tests takes too much time. Small changes can have big ripple effects. The main goal of automated unit tests is to find out if changes broke the code. However, 99% of the time what ends up breaking are the tests and not the code.

With all the above problems, there still isn't a better way to be able to make code changes and have some level of confidence that something didn't unexpectantly break than automating your tests.

Some of the above can be alleviated to some degree by not going by the textbook of unit testing.

EDIT: Instead, many types of designs/applications are better tested by automating tests at the module/package level. In my experience, most coding errors are not because the code in a class was coded incorrectly but because the coder didn't understand how their class was supposed to work with other classes. I have seen a lot of bang for the buck in this type of testing. But once again, these tests are harder to write than unit (class level) tests.

It really boils down to whether the developers believe in the process or not. If they do, then they'll write good unit tests, find errors early and be proponents. If they don't, then their unit tests will be by and large useless and won't find any errors and their theory of unit tests being useless will be proven true (in their minds).

Bottom line is that I've never seen the full blown automated unit testing approach work for more than a couple months myself, but the idea of automated unit tests still persists but we are selective in what really needs testing. This approach tends to have far less critics and is more accepted by all the developers rather than just a few.

In many ways I agree with your team.

1. Most unit tests are questionable in value. Since the vast majority of tests seem to be too simple.

2. It is much harder to write good testable code than just working code. There's a large percentage of the developer community that believes in just get it to work, versus code/design quality in itself. And an even larger percentage who don't even know what quality code is.

3. It can take much longer to write the unit test code than the actual code itself.

4. Figuring out how to adequately test the more complicated code (ie. the stuff you really are interested in thoroughly testing) is beyond many developers capabilities.

5. Maintaining unit tests takes too much time. Small changes can have big ripple effects. The main goal of automated unit tests is to find out if changes broke the code. However, 99% of the time what ends up breaking are the tests and not the code.

With all the above problems, there still isn't a better way to be able to make code changes and have some level of confidence that something didn't unexpectantly break than automating your tests.

Some of the above can be alleviated to some degree by not going by the textbook of unit testing, but it really boils down to whether the developers believe in the process or not. If they do, then they'll write good unit tests, find errors early and be proponents. If they don't, then their unit tests will be by and large useless and won't find any errors and their theory of unit tests being useless will be proven true (in their minds).

Bottom line is that I've never seen the full blown automated unit testing approach work for more than a couple months myself, but the idea of automated unit tests still persists but we are selective in what really needs testing. This approach tends to have far less critics and is more accepted by all the developers rather than just a few.

In many ways I agree with your team.

1. Most unit tests are questionable in value. Since the vast majority of tests seem to be too simple.

2. It is much harder to write good testable code than just working code. There's a large percentage of the developer community that believes in just get it to work, versus code/design quality in itself. And an even larger percentage who don't even know what quality code is.

3. It can take much longer to write the unit test code than the actual code itself.

4. Figuring out how to adequately test the more complicated code (ie. the stuff you really are interested in thoroughly testing) is beyond many developers capabilities.

5. Maintaining unit tests takes too much time. Small changes can have big ripple effects. The main goal of automated unit tests is to find out if changes broke the code. However, 99% of the time what ends up breaking are the tests and not the code.

With all the above problems, there still isn't a better way to be able to make code changes and have some level of confidence that something didn't unexpectantly break than automating your tests.

Some of the above can be alleviated to some degree by not going by the textbook of unit testing.

EDIT: Instead, many types of designs/applications are better tested by automating tests at the module/package level. In my experience, most coding errors are not because the code in a class was coded incorrectly but because the coder didn't understand how their class was supposed to work with other classes. I have seen a lot of bang for the buck in this type of testing. But once again, these tests are harder to write than unit (class level) tests.

It really boils down to whether the developers believe in the process or not. If they do, then they'll write good unit tests, find errors early and be proponents. If they don't, then their unit tests will be by and large useless and won't find any errors and their theory of unit tests being useless will be proven true (in their minds).

Bottom line is that I've never seen the full blown automated unit testing approach work for more than a couple months myself, but the idea of automated unit tests still persists but we are selective in what really needs testing. This approach tends to have far less critics and is more accepted by all the developers rather than just a few.