It is my strong opinion that unit tests' value is largely underestimated by many teams because of several factors, many already highlighted in the answers.

Often developers are under pressure to "get things done", so proving that a code block works is a sufficient proof for the customer. This almost always applies to consulting company and human-driven QA: if the customer doesn't require unit testing and coniders a live demo sufficient then the customer has totally failed since he's going to sign approval for code that might hide faults.

Often developers are frustrated. Being a programmer is a hard job: finishing a task and going to the next is satisfying, so everyone wants to hurry and finish. Until they get hit by a bus with a major bug that rises months after original QA. In this scenario, automated and continuous QA is a management's problem rather than developers (they'll still get paid for their work, perhaps overtime).

###But there is an exception

I strongly believe that the acceptance of the automated test model is a function of the "humanness" of the tests being done. If you are testing a web module with a front end, you are more likely, despite tools such as Selenium, to fill the form by yourself, see the result and believe in determinism. You'll forget to re-run tests later or you'll just be too lazy to do old tests again, and this is why bugs sometimes get discovered later. To leverage this, a strong modularization of the code and strict rules on "modifying old code" have been proved acceptable in a banking environment (in my personal work experience).

Instead, if the developer is in charge of developing a highly-automated and high-volume-data module, he'll be more likely to write thorough unit tests and submit them to the test batches. This because filling a large XML payload with data converted from an external data source (mocked or not) is not a human-prone job. Some test developers will eventually build a tiny and funny front end for this specific kind of tests. When I worked at my Master's thesis I was working on a logging bus that handled 6000+ syslog messages per second and I had to measure packet loss and corruption: I naturally wrote unit and stress tests for almost all components, especially the Syslog parser.

###In order to make developers more unit test-prone

I believe they must be forced to. If you are a smart customer you'll require your consultants to run the full test suite at every QA. If you are a good team leader you may think assigning the following task to a smart developer: build an inner-test platform. That has nothing to see with inner effect platform antipatter, but instead is a set of helper classes, database mocks, configurations, parsers, converters, swiss army knives to help developers build tests in no time.

Current testing platforms such as NUnit are general-purpose and allow you to verify generic assertions. Correctly using dependency injection and project-specific factories help developers write less code for tests and be happier. I haven't had the chance yet to experiment this on a full project, I can't provide real-life feedback.

It is my strong opinion that unit tests' value is largely underestimated by many teams because of several factors, many already highlighted in the answers.

Often developers are under pressure to "get things done", so proving that a code block works is a sufficient proof for the customer. This almost always applies to consulting company and human-driven QA: if the customer doesn't require unit testing and coniders a live demo sufficient then the customer has totally failed since he's going to sign approval for code that might hide faults.

Often developers are frustrated. Being a programmer is a hard job: finishing a task and going to the next is satisfying, so everyone wants to hurry and finish. Until they get hit by a bus with a major bug that rises months after original QA. In this scenario, automated and continuous QA is a management's problem rather than developers (they'll still get paid for their work, perhaps overtime).

But there is an exception

I strongly believe that the acceptance of the automated test model is a function of the "humanness" of the tests being done. If you are testing a web module with a front end, you are more likely, despite tools such as Selenium, to fill the form by yourself, see the result and believe in determinism. You'll forget to re-run tests later or you'll just be too lazy to do old tests again, and this is why bugs sometimes get discovered later. To leverage this, a strong modularization of the code and strict rules on "modifying old code" have been proved acceptable in a banking environment (in my personal work experience).

Instead, if the developer is in charge of developing a highly-automated and high-volume-data module, he'll be more likely to write thorough unit tests and submit them to the test batches. This because filling a large XML payload with data converted from an external data source (mocked or not) is not a human-prone job. Some test developers will eventually build a tiny and funny front end for this specific kind of tests. When I worked at my Master's thesis I was working on a logging bus that handled 6000+ syslog messages per second and I had to measure packet loss and corruption: I naturally wrote unit and stress tests for almost all components, especially the Syslog parser.

In order to make developers more unit test-prone

I believe they must be forced to. If you are a smart customer you'll require your consultants to run the full test suite at every QA. If you are a good team leader you may think assigning the following task to a smart developer: build an inner-test platform. That has nothing to see with inner effect platform antipatter, but instead is a set of helper classes, database mocks, configurations, parsers, converters, swiss army knives to help developers build tests in no time.

Current testing platforms such as NUnit are general-purpose and allow you to verify generic assertions. Correctly using dependency injection and project-specific factories help developers write less code for tests and be happier. I haven't had the chance yet to experiment this on a full project, I can't provide real-life feedback.