可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试):

问题:

I have recently heard of Functional Testing over Unit Testing.

I understand that Unit Testing tests each of the possibilities of a given piece of code from its most atomic form. But what about Functional Testing?

This sounds to me like only testing if the code works, but is it as reliable as Unit Testing?

I've been told there was two school of thoughts for the matter. Certains would prefer Unit Testing, others Functional Testing.

Is there any good resources, links, books, any references or one of you all who can explain and elighten my path on the subject?

Thanks!

回答1:

Jason's answer is correct. Different types of tests have different purposes, and can be layered for best results (good design, meeting specifications, reduced defects).

Unit testing = drives design (with Test-Driven Development, or TDD)
Integration testing = do all the pieces work together
Customer acceptance testing = does it meet the customer's requirements
Manual testing = often covers the UI; dedicated testers can find what automation misses
Load testing = how well does the system perform with realistic amounts of data

There is some overlap between these categories; unit tests can specify behavior, for instance.

And there are others; for more than most people care to know, see Software Testing.

One point people missed is that unit testing is testing pieces of code in isolation. Good unit tests don't hit the database, for instance. This has two advantages: it makes the tests run fast so you'll run them more often, and it forces you to write loosely coupled classes (better design).

You asked for resources; I recommend Roy Osherove's book The Art of Unit Testing with Examples in .NET. While no book is perfect, this one gives many excellent pointers on writing good tests.

EDIT: And for writing tests against existing software, nothing beats Michael Feathers' book Working Effectively with Legacy Code.

回答2:

Unit testing versus functional testing is not an xor, but rather an and. Unit testing is about testing units in isolation while functional testing is about testing the whole in integration (do all the units works together properly?).

Both are necessary components of good software engineering practices.

回答3:

Unit testing tests your code units (methods, etc) to make sure they do what you expect them to.

Functional testing tests your system design to make sure the pieces interact correctly. If you write a command that takes and int and returns a string and test it fully, you can be sure it works. But if you don't have system tests, you may never notice that the rest of the code thinks it can accept a null but it can't.

Both types of testing are important.

edit: To add a slightly different view to what gbjbaanb said:

Unit test = my code works
Functional test = my design works
Integration test = my code is using your 3rd party stuff correctly (databases, etc)
Factory Acceptance Test = my system works
Site Acceptance Test = your code sucks, this totally isn't what I asked for!?!

回答4:

Unit test = lowest, granular level.
Functional test = middling, modular level.
Integration test = higher application level.
Factory Acceptance Test = see it all work
Site Acceptance Test = see it all fail :)

All the above are useful but they're not mutually exclusive. You should be doing most of them but the amount of time you spend on each part depends on the results you get from them, that's all. If your code is too modular to be easily unit tested, then spend your efforts on the functional tests. If you're writing a library of small components, spend your time on unit testing them, and if you're writing control systems for military missiles you should definitely be site acceptance testing them (as explosions even when it fails is fun :) )

回答5:

Functional testing, also called System testing, aims at testing the complete system, and verifying the functional requirements are satisfied.

Unit testing aims at testing the "units", i.e. the functions or methods the system is build from in isolation. It's sometimes called Developer testing. Unit testing can be hard after the fact, that's why TDD writes the test before the code.

Those are complementary as the units can work independently and not when integrated all together, or they can pass the unit tests, and not fulfill all the product requirements.

回答6:

Unit Testing and Functional Testing have two different results.

Unit Testing verifies that a small piece of code works as expected. It is usually done by the developer to ensure that the code works correctly. They are usually automated by a testing-framework as well.

Functional Testing verifies that a feature works as expected by going through a certain pathway through the program. They are usually executed by a person on the software ensuring that the program will work they way it is supposed to for the user. It, as such, is higher level, and thus tests several units at once.

I think both are important. If you have limited resources, though, and have to pick/choose techniques, and I think it depends on the products you create, but for what I do (automotive control products used by humans through some buttons) functional tests are most important. It checks, and ensures, that when the user gets the product, it does what it is supposed to do. This doesn't mean we should opt out of unit testing, but if push-comes-to-shove, functional is the most important to ensure great user experience and getting the product out the door.

If you produce, say, a database engine (or some other product that isn't necessarily user-facing), unit testing may be what you really ought to do.

回答7:

A Unit Test tests a piece of Code and confirms for a programmer that another piece of code is doing what it is supposed to. In Test Driven Development, the unit test is written first and observed to fail, before the code is written causing the test to pass. Programmers are interested in Unit Tests. Unit Test are quick to execute.

A Function Test tests your black box requirement and demonstrates that a piece of user functionality is in place. For example, if I press the big red button, the bell begins to ring. The functional test mightn't even be testing code. Perhaps there is a mechanical process that cause the bell to ring having pressed the button. Customers are interested in Functional Tests as they confirm that a high level process if working in a manner that they understand. They are often slow to execute.