.net - Component vs Integration vs Functional tests -

recently figured out understanding of different types of tests maybe not right.

e.g. unit test testing of 1 unit interaction other units based on mocks (fakes, stubs). so, no interaction file system, threads, time...

component tests, me, tests around 1 component (more units) used both, mocks , "real" resources. both of them used input simulation , output tests. whatever seemed more appropriate. e.g. mocking change of current arbitration state, asserting events stored rtdb.

these components, me, slices of 1 application.

functional tests considered (black box) tests around application (exe) runs in production.

well, true or not? component tests based on mocks? if yes, why? how can sure mocks enough? should run application functional tests or not? why different bootstrap of app main routine in thread? integration tests?

i hear other opinions , how do that. tests have, how maintain them , responsible them in team?

cheers!

your question unfocused, nevertheless try give answer.

various kinds of tests have been discussed here: what unit test, integration test, smoke test, regression test?

it is, however, not use of doubles (like mocks, stubs etc.) distinguishes different kinds of tests. goal pursue different tests distinguishes them.

in unit-testing, goal test piece of code write behaves as expect behave. is, testing code against assumptions of how code should behave. doubling (mocking) means achieve goal while @ same time ensuring a) testing of scenarios (including error cases) b) deterministic test results (independent timing / scheduling / environment conditions) c) fast test build , execution d) easy test setup e) independence problems libraries (incomplete, buggy, ...). don't have double library if can achieve these criteria use of real library. example, in cases don't create doubles container libraries (lists, sets, maps, ...) part of standard library of programming language - typically reach unit-test goals using library.

it not goal of unit-testing identify misconceptions how interact other software parts. and, since not mandatory fine double software parts unit interacts with, in case not able identify such misconceptions: whenever double 1 of dependencies, implementing double according understanding (and, possibly, misconceptions) of other component. thus, identification of misconceptions how interact other components goal of integration testing. in integration testing bring components, interactions between want test. additional components, again, can linked in or doubled, depending on similar criteria unit-testing.

once realize different goals of unit-tests , integration-tests realize different goals lead construction of different sets of test cases. therefore, unit-test suite remains unit-test suite, no matter if can along linking real libraries instead of using doubles.

then, (sub-)system-testing brings in different goals again, example test set of components implement required feature of (sub-)system. example components , b operate on list of structures, , among other things, final list shall sorted. now, developers of , b might assume other doing sorting. and, if neither of them require data sorted own code, a) both components have unit-test suites don't test output being sorted, , b) there integration tests interaction between , b don't test input other comes sorted. (sub-)system testing, however, existence of required features tested , missing sort detected. again, additional components in environment of (sub-)system test can linked in or doubled - both scenarios possible.

you are, however, asking component-testing, either synonym (sub-)system testing, or term describing combination of (sub-)system testing , integration tests components form (sub-)system. and, functional tests mention (sub-)system tests on level of software system (therefore, not sub- system tests). and, answering question understand it, should have become clear use of doubles not reliable criterion classify test suites, respective goal of tests is.