Manual tests and unit tests are designed for different purposes^*, so the answer is “yes” – substituting one for the other is a dangerous practice.

Unit tests pin down your assumptions about your code in the form of assertions that you make throughout your tests. Along with automated integration tests, unit tests help ensure that your software does what you think it should do. When done correctly, they should give you a high level of confidence in the correctness of your software. Automated testing is not as time-consuming, and much less error-prone.

However, it is often impractical to eliminate all manual testing. Specific areas of concern include integration with other products that you must use, such as installers, web browsers, and operating systems. At the minimum, someone needs to install your product before shipping, and see if it starts up, or open your product in the browser to see if the visuals remain in the right places. All of that can be automated, but the effort to make it happen does not make it worth the trouble, especially since we are talking about running through a ten-minute checklist.

If we are talking about the specific “manual tests vs. unit tests” distinction, the two concepts do not slice the space of software testing in the same dimension: in addition to unit tests, you need integration tests, regression tests, and stress tests. These are usually automated, but they can be done manually. Moreover, even the unit testing can be done manually with a small help of a software driver. That’s why substituting one for the other is not a good comparison: if your manual testing covers unit testing, regression testing, stress testing, and integration testing, then replacing it with automated unit testing is not a fair exchange. If the gap is filled with some other mean of automated testing, then you can shift some burden from the manual testing to unit testing, but you would not be able to eliminate manual testing completely.

^* As Jimmy Hoffa correctly notes, there are companies who (mis)use manual testing in the areas where unit testing is a lot more appropriate. In cases like that, switching to unit tests is not dangerous – in fact, it is highly desirable.

Automated unit tests answer the question ‘Does it do what I thought I asked it to do?’ while manual testing answers the question ‘Does it do something that seems sensible to a user?’.

Different questions. And if you substitute the methods for testing one for the other, you’ll tend to get sub-optimal results.

When you say “Manual testing” I take it you mean an entire system/program? If so this is not the same as unit testing and is more akin to user testing. Unit tests (should) target a very specific piece of code (a method/property on a class) and test it in isolation. Unit tests are also tests written by developers for developers. Manual testing (I will assume you mean user based testing) is for the users of the system often done (if your lucky) by testers for the product owner/sponsor. You should end up with a lot more unit tests than user tests because they are testing a smaller degree of scenario. So, I would say yes it is dangerous to substitute unit tests for manual testing because in doing so you probably will end up testing less specific things which could lead to more bugs slipping through.

Its also worth noting that unit tests are quick. Do you have time to run 1000’s of manual tests everytime you make code changes?

Unit tests are important, not the be-all and end-all of testing. The primary purpose is not to find bugs as you write and run the test, but to highlight when expected behaviour changes in the future (and consequently regression bugs).

They certainly don’t serve the same purpose that testing with users does.