testing - What's the difference between unit, functional, acceptance, and integration tests? -

what difference between unit, functional, acceptance, , integration testing (and other types of tests failed mention)?

depending on look, you'll different answers. i've read subject lot, , here's distillation; again, these wooly , others may disagree.

unit tests

tests smallest unit of functionality, typically method/function (e.g. given class particular state, calling x method on class should cause y happen). unit tests should focussed on 1 particular feature (e.g., calling pop method when stack empty should throw invalidoperationexception). touches should done in memory; means test code and code under test shouldn't:

• call out (non-trivial) collaborators
• access network
• hit database
• use file system
• spin thread
• etc.

any kind of dependency slow / hard understand / initialise / manipulate should stubbed/mocked/whatevered using appropriate techniques can focus on unit of code doing, not dependencies do.

in short, unit tests simple possible, easy debug, reliable (due reduced external factors), fast execute , prove smallest building blocks of program function intended before they're put together. caveat that, although can prove work in isolation, units of code may blow when combined brings ...

integration tests

integration tests build on unit tests combining units of code , testing resulting combination functions correctly. can either innards of 1 system, or combining multiple systems useful. also, thing differentiates integration tests unit tests environment. integration tests can , use threads, access database or whatever required ensure of code and different environment changes work correctly.

if you've built serialization code , unit tested innards without touching disk, how know it'll work when loading , saving disk? maybe forgot flush , dispose filestreams. maybe file permissions incorrect , you've tested innards using in memory streams. way find out sure test 'for real' using environment closest production.

the main advantage find bugs unit tests can't such wiring bugs (e.g. instance of class unexpectedly receives null instance of b) , environment bugs (it runs fine on single-cpu machine, colleague's 4 core machine can't pass tests). main disadvantage integration tests touch more code, less reliable, failures harder diagnose , tests harder maintain.

also, integration tests don't prove complete feature works. user may not care internal details of programs, do!

functional tests

functional tests check particular feature correctness comparing results given input against specification. functional tests don't concern intermediate results or side-effects, result (they don't care after doing x, object y has state z). written test part of specification such as, "calling function square(x) argument of 2 returns 4".

acceptance tests

acceptance testing seems split 2 types:

standard acceptance testing involves performing tests on full system (e.g. using web page via web browser) see whether application's functionality satisfies specification. e.g. "clicking zoom icon should enlarge document view 25%." there no real continuum of results, pass or fail outcome.

the advantage tests described in plain english , ensures software, whole, feature complete. disadvantage you've moved level testing pyramid. acceptance tests touch mountains of code, tracking down failure can tricky.

also, in agile software development, user acceptance testing involves creating tests mirror user stories created by/for software's customer during development. if tests pass, means software should meet customer's requirements , stories can considered complete. acceptance test suite executable specification written in domain specific language describes tests in language used users of system.

conclusion

they're complementary. it's advantageous focus on 1 type or eschew them entirely. main difference me of tests @ things programmer's perspective, whereas others use customer/end user focus.