What are the Pros and Cons of Manual Unit Testing against the Automated Unit Testing?

Question

Can I get the advantages and disadvantages of Manual Unit Testing compare to the Automated process.

Answer 1

I assume that "manual testing" means testing without a testing library.

Pros of "manual testing":

• One-off projects
• No need to learn the rules of a library

Cons of "manual testing":

• Will likely cause chaos/bitterness in a team environment
• Extensive work has already gone into testing libraries

Consensus:

Please Use a Testing Library

Not using a popular testing library is a very bad habit and you will definitely regret going down this road just like I did. Now that I've been stung by the ghost of old code I use Jest wherever I can.

Answer 2

"Manual Unit Testing" is pretty much impossible. Unit testing is defined as testing small units of code in isolation. You can't really do that manually.

Now, if you're talking about integration testing, that's a different matter:

Pro manual integration tests:

• Testers are cheaper than developers
• Testers can intelligently adjust the tests to changes in the application - they're not as inherently brittle as automated tests
• Testers can spot bugs that an automated test might miss (such as missing or incorrect values that are not explicitly tested for, or layout problems)
• Doesn't require extra testing software which can be costly and/or take a lot of time to learn
• Always possible; there are no technical requirements you have to meet
• You can just start; the initial costs to do a single test are much lower than for setting up and implementing an automated test.

Con manual integration tests:

• You have to pay a human every time you do them. In the long run, that's very, very expensive.
• Full regression testing after bug fixes is basically impossible (too expensive).
• This means that you have to be very conservative with changes late in the development cycle, and big changes in general. No constant refactoring - better live with bad code than risk catastrophic side effects.
• You have to plan very carefully when you'll do the testing to get the maximum value for money. To some degree, you'll have to adjust your development practices to reflect that.

All in all, it's best to have both manual and automated integration tests; these can sometimes complement each other well, as some things can in fact be easier to test in an automated way, while others can't be automated at all.

Answer 3

I think the only real answer to your question is it doesn't matter, because you have to have both.

Automated unit tests will allow your developers to code tests that automatically validate code according to their understanding of the specifications. Since they are automated they can be run over and over again with little or no variation each time. By definition these unit tests will know how the software works, under-the-hood, and as such can be considered as white box testing -- the tests are aware of some if not all of the underlying code.

Manual testing will, on the other hand, reveal problems from the point-of-view of users. You will have the ability to find out what errors can be encountered by entities not familiar with the underlying code and structure, as well as if there are problems with regards to the usability of your program. This is considered as black box testing.

Answer 4

Strange question - unit testing is supposed to be automatic, thus repeatable and easy to run. For many (including me) "manual unit test" is a contradiction in terms.

Manual testing may be useful in those cases when one can't make automated tests. These typically are not at the unit test level, but higher - e.g. integration, GUI, stress etc. tests.

With unit tests, you are testing small pieces of your code (typically individual methods/classes) at a time. The tests are written in code themselves, so they can (almost always) be run automatically by a unit testing framework.

Update: now that you give a more concrete context to your question, it is easier to give a concrete answer :-)

I am convinced to say that automated unit tests practically always pay for themselves many times over the lifetime of a SW project. Setting them up is costlier than manual testing, but the more you run them, the more time you save - and the more early feedback you get about where your code is broken by new changes.

Covering legacy code with unit tests is definitely not easy, but if the product is valuable for your company and is expected to be continued for years, it is still a worthy effort. Especially so since in real life, a production system tends to outlive its expected lifetime.

One aspect is, you "try to check all the code paths we've written" - with automated unit tests combined with a code coverage tool, you can automagically see - often right within your IDE, if the coverage tool is integrated well - what code paths are not covered by your latest unit tests.

I recommend Working Effectively with Legacy Code - it contains a wealth of valuable knowledge on how to write unit tests for tangled, badly written legacy code.