This is a revised analysis of considerations of when to implement unit testing.
Systems range from contiguous (integrated or single-component) to separated (componetised).
Components range in degree of isolation. The less isolation, the more integration. There are two ways integration is increased:
- When a component uses data or methods that are outside of it, but not a parameter to the component
- When a component changes data that is outside of it
Complete isolation of all components is generally prohibitively inefficient. Things like standard libraries, model schemas, framework tools, database connections are generally integrated because there is little benefit in de-integrating these things that rarely change.
A unit test involves isolating a component, and then following the steps of
- determine the possible range of inputs
- set the expected range of results
- test the possible range of inputs, comparing against expected range of results
Integration testing is treating the system as a unit test, wherein the range becomes the combinations of ranges of the components.
Whether to introduce a test is based on these factors:
- importance of the function working as expected
- financial transaction vs youtube video
- is the code used as a library or only for a specific software
- the potential for the function not to work as expected
- reliance on changeable environment
- the likelihood of and capacity for misuse by other developers
- are inputs checked, or is checking not-practical due to wide ranges
- is the programming language typed
- quality of documentation
- quality of other developers
- the cost of making the test
- the degree of isolation
- the ranges involved
The practicality of web development unit tests was generally less than in other areas of software because:
- most components are not complex - they usually don’t involve algorithms of any complexity
- most components are highly integrated: server, browser, database, files, caching, sessions
- most important functionality involves multiple components, and is tested with integration testing
- many components are particular to one website
However, software development has changed significantly. There has been an influx of developers, many of whom are below the par of previous decades. There has been an extraordinary push to avoid custom builds in favor of aggregating existing components. Non-linear programming, such as that used with promises or concurrency, has increased the potential complexity of single components. Extensive Api use has increased the potential functions will not work as expected. These realities make unit testing, for most development teams, a necessity.
This does not, however, mean that single developers or small, tight, development teams building single purpose applications should build unit tests.