Testing: Difference between revisions
From ym2149.org
Jump to navigationJump to search
No edit summary |
mNo edit summary |
||
| (One intermediate revision by the same user not shown) | |||
| Line 2: | Line 2: | ||
* unit tests are supposed to be fast so developers can run them frequently without getting bored | * unit tests are supposed to be fast so developers can run them frequently without getting bored | ||
* your 'test doubles' are dysfunctional if they involve writing things twice, use lightweight mocks | * your 'test doubles' are dysfunctional if they involve writing things twice, use lightweight mocks | ||
** in a language without static types, even lightweight mocks are redundant as the test harness can be passed in where collaborators normally would be | |||
* unit tests are for verifying behaviour and enforcing it | * unit tests are for verifying behaviour and enforcing it | ||
* an integration test can be used to check the parts unit tests can't reach, in particular that the service can communicate with its immediately adjacent services | * an integration test can be used to check the parts unit tests can't reach, in particular that the service can communicate with its immediately adjacent services | ||
| Line 7: | Line 8: | ||
== Analogy == | == Analogy == | ||
* a dishwasher gets dishes clean by splashing them gently. if you tried that you'd get nowhere, but the machine is relentless and thorough - that's the difference between manual and automated testing | * a dishwasher gets dishes clean by splashing them gently. if you tried that yourself you'd get nowhere, but the machine is relentless and thorough - that's the difference between manual and automated testing | ||
[[Category:Programming]] | [[Category:Programming]] | ||
Latest revision as of 12:38, 19 April 2024
- manual testing is a terrible use of resource, invest in automated testing whenever possible
- unit tests are supposed to be fast so developers can run them frequently without getting bored
- your 'test doubles' are dysfunctional if they involve writing things twice, use lightweight mocks
- in a language without static types, even lightweight mocks are redundant as the test harness can be passed in where collaborators normally would be
- unit tests are for verifying behaviour and enforcing it
- an integration test can be used to check the parts unit tests can't reach, in particular that the service can communicate with its immediately adjacent services
Analogy
- a dishwasher gets dishes clean by splashing them gently. if you tried that yourself you'd get nowhere, but the machine is relentless and thorough - that's the difference between manual and automated testing
