From 21f2064a14478a7f1b59be1696f01ffe34e945f0 Mon Sep 17 00:00:00 2001 From: alex Date: Sun, 30 Aug 2026 17:15:32 +0200 Subject: Add /notes/tech/on-testing softwareengineering.stackexchange started giving me captchas when referring to the London/Chicago testing terms, so I refactored out the testing bits in /notes/interesting-articles to a new article. --- blog/content/notes/interesting-articles.gmi | 13 +------------ blog/content/notes/tech/on-testing.gmi | 23 +++++++++++++++++++++++ 2 files changed, 24 insertions(+), 12 deletions(-) create mode 100644 blog/content/notes/tech/on-testing.gmi diff --git a/blog/content/notes/interesting-articles.gmi b/blog/content/notes/interesting-articles.gmi index 78ba6995..d7d1cfc2 100644 --- a/blog/content/notes/interesting-articles.gmi +++ b/blog/content/notes/interesting-articles.gmi @@ -41,16 +41,7 @@ The history about Hungarian notations => https://www.hillelwayne.com/post/we-are-not-special/ We are not special Second of a series of three articles comparing software engineering with traditional engineering. Mostly dispels some myth and lack of knowledge about traditional engineering. -### Testing - -=> https://testing.googleblog.com/2014/05/testing-on-toilet-risk-driven-testing.html Testing on the Toilet: Risk-Driven Testing -"Your tests are a means. The bang is what counts. It’s your job to maximize it." - -=> https://testing.googleblog.com/2024/10/smurf-beyond-test-pyramid.html SMURF: Beyond the Test Pyramid -Test categories and the pyramid are excessively limited models. - -=> https://abseil.io/resources/swe-book/html/ch11.html#the_beyonceacutesemicolon_rule The Beyoncé Rule -"If you liked it, then you shoulda put a test on it." +=> tech/on-testing See also my own "on testing" for further notes about testing, including risk-driven testing, the Beyoncé rule, SMURF, test doubles (dummies, fakes, stubs, spies, and mocks), and classic/mockist testing (also Chicago/Detroit/London). ### Python @@ -175,8 +166,6 @@ A type of human behavior reactivity in which individuals modify an aspect of the => https://en.wikipedia.org/wiki/Novelty_effect Novelty effect An effect of introducing new elements on some activity or behavior. -=> https://softwareengineering.stackexchange.com/questions/123627/what-are-the-london-and-chicago-schools-of-tdd What are the London and Chicago schools of TDD? - => https://en.wikipedia.org/wiki/Sturgeon%27s_law Sturgeon's law An adage stating "ninety percent of everything is crap". diff --git a/blog/content/notes/tech/on-testing.gmi b/blog/content/notes/tech/on-testing.gmi new file mode 100644 index 00000000..5bcccaa2 --- /dev/null +++ b/blog/content/notes/tech/on-testing.gmi @@ -0,0 +1,23 @@ +# On testing + +This document is mostly a collection of links with some annotations. + +=> https://testing.googleblog.com/2014/05/testing-on-toilet-risk-driven-testing.html Your tests are a means. The bang is what counts. It’s your job to maximize it. + +=> https://abseil.io/resources/swe-book/html/ch11.html#the_beyonceacutesemicolon_rule The Beyoncé Rule says that you should test automatically anything you don't want to break. The Beyoncé rule also implies that you can break things that are not tested. + +=> https://testing.googleblog.com/2024/10/smurf-beyond-test-pyramid.html Test categories and the pyramid are excessively limited models; SMURF evaluates tests along the tradeoffs of speed, maintainability, utilization (resource usage), reliability, and fidelity. Instead of spending effort thinking about test types, try to write tests that cover what you do not want to break (as per the Beyoncé rule above) while balancing the SMURF tradeoffs. + +Test doubles are components that replace parts of a system in a test. The following documents explain different kinds of useful test doubles: + +=> https://testing.googleblog.com/2013/07/testing-on-toilet-know-your-test-doubles.html Know Your Test Doubles + +=> https://martinfowler.com/articles/mocksArentStubs.html Mocks Aren't Stubs + +"Mocks Aren't Stubs" also discusses the classic and mockist test styles (the classic style is also known as Detroit or Chicago style or school, while the mockist style is known as London style or school). Classic testing validates state, using doubles only when necessary (probably because of SMURF tradeoffs); mockist testing verifies interactions by using mocks. + +(My personal opinion is similar to Martin Fowler's in "Mocks Aren't Stubs", you should use classic testing and structure your programs to simplify classic testing, unless for specific scenarios where mocks are better, such as the example posed by Martin: + +> A great example of this is a cache. The whole point of a cache is that you can't tell from its state whether the cache hit or missed - this is a case where behavior verification would be the wise choice for even a hard core classical TDDer. I'm sure there are other exceptions in both directions. + +You should also reduce the use of doubles as much as possible within the SMURF tradeoffs, probably also influencing the structure of your programs.) -- cgit v1.2.3