They are many reasons why introducing automated testing might fail. I think that it boils down to the fact that programmers tend not to change their coding habits and are not fully capable of embracing unit testing.

Many people who want to start with automated testing try to introduce them for an existing code base. They will try to write integration tests which test a lot of functionality of existing application at once. Such integration tests are notoriously too hard and too expensive to maintain. Advice: Introduce automated tests for a new code base.

Unit tests are good tests to be automated. Everything above (integration tests, component tests, system tests) can be also tested automatically, but the cost-benefit ratio rapidly declines the more functionality is tested at once. This negative effect is amplified, if you build such tests on poorly unit-tested functionality. Advice: Introduce automated tests on the unit test level and build automated integration tests on a solid foundation of unit tests.

From the points above much of the success of automated testing depend on how effective the unit tests are. You have effective unit tests if you feel productive with unit tests. When people start with unit testing, they tend to retrofit their existing code and coding habits into unit tests. Ironically this is the hardest way to learn unit testing. Also unit testing requires you change the way how you code (for instance applying the SOLID principles ). Advice: Learn unit testing from the ground up with new code and deal with the fact that you need to change your coding habits.

There are a lot other factors, but I found that for most programmers it is troublesome to change their way to code. Code written without test just looks different. If cannot squeeze your code into a testable design, you will very probably fail to write effective unit tests. This destroys the ground for effective automated testing.

I experienced that by myself and I am now happy to work in a company which successfully introduced automated tests. I could write a lot more about the other factors, but I think that coding habits and unit testing are the most important ones. Luckily there are others who have more experience than me and fill books with their know-how. One of these books is Brownfield Application Development in .NET which I can really recommend, since you are using the Microsoft technology stack.

They are many reasons why introducing automated testing might fail. I think that it boils down to the fact that programmers tend not to change their coding habits and are not fully capable of embracing unit testing.

Many people who want to start with automated testing try to introduce them for an existing code base. They will try to write integration tests which test a lot of functionality of existing application at once. Such integration tests are notoriously too hard and too expensive to maintain. Advice: Introduce automated tests for a new code base.

Unit tests are good tests to be automated. Everything above (integration tests, component tests, system tests) can be also tested automatically, but the cost-benefit ratio rapidly declines the more functionality is tested at once. This negative effect is amplified, if you build such tests on poorly unit-tested functionality. Advice: Introduce automated tests on the unit test level and build automated integration tests on a solid foundation of unit tests.

From the points above much of the success of automated testing depend on how effective the unit tests are. You have effective unit tests if you feel productive with unit tests. When people start with unit testing, they tend to retrofit their existing code and coding habits into unit tests. Ironically this is the hardest way to learn unit testing. Also unit testing requires you change the way how you code (for instance applying the SOLID principles ). Most programmers soon stop writing unit tests because they think that the learing curve is too steep and find it awkward to wrap unit tests around a not so testable designed code. Advice: Learn unit testing from the ground up with new code and deal with the fact that you need to change your coding habits.

There are a lot other factors, but I found that for most programmers it is troublesome to change their way to code. Code written without test just looks different. If you cannot squeeze your code into a testable design, you will very probably fail to write effective unit tests. This destroys the ground for effective automated testing.

I experienced that by myself and I am now happy to work in a company which successfully introduced automated tests. I could write a lot more about the other factors, but I think that coding habits and unit testing are the most important ones. Luckily there are others who have more experience than me and fill books with their know-how. One of these books is Brownfield Application Development in .NET which I can really recommend, since you are using the Microsoft technology stack.