The testing pyramid is an aspirational goal that suggests that the number of tests in a category, and the frequency of their execution, should be inversely proportional to the cost and scope of that category.
You should have a lot of cheap fast unit tests, written by programmers, and that cover nearly 100% of the code.
QA and business analysts should write fewer, but still many, acceptance tests, covering the code that is reachable by then. (~50%) of the whole.
Architects and tech leads should write a few integration tests that ensure that the plumbing and choreography of the components is working. These tests cover <~10% of the code, have a broad scope, require many resources, and can be slow.
QA and business analysts should write a very few system level tests that are the final tests of plumbing and choreography. They cover very little of the actual business rules and code and concentrate on systemics. These tests are very expensive in time and resources.
A vanishingly small number of manual exploratory tests cap the pyramid.
The bottom two layers are the traditional content of the continuous build. Layers above that are executed less frequently as you climb upwards.
The vast majority of systems require only the bottom two layers. The upper layers become more populated as system complexity and size increases.
Some smallish systems require only the bottom layer. (e.g. more-speech)
And it goes without saying that all but the manual tests are automated.
unclebobmartin /
npub19m…njnft
2023-02-28 16:30:44
Author Public Key
npub19mun7qwdyjf7qs3456u8kyxncjn5u2n7klpu4utgy68k4aenzj6synjnftSeen on
wss://relay.nostr.bandPublished at
2023-02-28 16:30:44Event JSON
{
"id": "00001644e9c9938bfdbdaee9f975fd427b600ef4aa313db076a5c6b2b8520826",
"pubkey": "2ef93f01cd2493e04235a6b87b10d3c4a74e2a7eb7c3caf168268f6af73314b5",
"created_at": 1677601844,
"kind": 1,
"tags": [
[
"subject",
"The Test Pyramid"
],
[
"client",
"more-speech - 2023-02-21T15:39"
],
[
"nonce",
"14001",
"16"
]
],
"content": "The testing pyramid is an aspirational goal that suggests that the number of tests in a category, and the frequency of their execution, should be inversely proportional to the cost and scope of that category. \n\nYou should have a lot of cheap fast unit tests, written by programmers, and that cover nearly 100% of the code. \n\nQA and business analysts should write fewer, but still many, acceptance tests, covering the code that is reachable by then. (~50%) of the whole.\n\nArchitects and tech leads should write a few integration tests that ensure that the plumbing and choreography of the components is working. These tests cover \u003c~10% of the code, have a broad scope, require many resources, and can be slow.\n\nQA and business analysts should write a very few system level tests that are the final tests of plumbing and choreography. They cover very little of the actual business rules and code and concentrate on systemics. These tests are very expensive in time and resources.\n\nA vanishingly small number of manual exploratory tests cap the pyramid. \n\nThe bottom two layers are the traditional content of the continuous build. Layers above that are executed less frequently as you climb upwards.\n\n\nThe vast majority of systems require only the bottom two layers. The upper layers become more populated as system complexity and size increases. \n\nSome smallish systems require only the bottom layer. (e.g. more-speech)\n\nAnd it goes without saying that all but the manual tests are automated.",
"sig": "9a8067544febbea11882c138eff98c1612f16ec110c0ef30aec204ad3a55e284bb272bedee164750bf911ef11da8b348371411b9b8d63161aee04ff46ec70d00"
}