Skip to content

Instantly share code, notes, and snippets.

@seanmhanson

seanmhanson/ableismSanityCheck.md

Created April 3, 2017 16:17
Show Gist options
  • Save seanmhanson/fe370c2d8bd2b3228680e38899baf5cc to your computer and use it in GitHub Desktop.
Save seanmhanson/fe370c2d8bd2b3228680e38899baf5cc to your computer and use it in GitHub Desktop.
Download ZIP
Ableist Language in Code: Sanity Check
Raw
ableismSanityCheck.md

Ableist Language in Code: Sanity Check

Removing ableist language in code is important; it helps to create and maintain an environment that welcomes all developers of all backgrounds, while emphasizing that we as developers select the most articulate, precise, descriptive language we can rather than relying on metaphors. Quite simply, avoiding ableist language lets us make sure we are inclusive of all developers, while moving toward language that is simultaneously more acccessible to developers whose first language might not be our own.

The phrase sanity check is ableist, and unnecessarily references mental health in our code bases. It denotes that people with mental illnesses are inferior, wrong, or incorrect, and the phrase sanity continues to be used by employers and other individuals to discriminate against these people.

There are a ton of alternatives, and one of the best ways to select one is to ask yourself: What am I actually checking? and select something more descriptive. In everyday conversation, we can simply drop the idiom completely and say something akin to Let's check to ensure everything is working.

If this doesn't help, consider one of these many alternatives. I'm prone to using the first two in my own code, though these are gleaned from many developers:

  • Quick check
  • Initial check
  • Confidence check
  • Coherence check
  • Soundness check
  • Calibration check
  • Rationality check

One to avoid? Health check. Along with again tieing in discussions of health and disability, this phrase already carries a lot of previous implications from other products that may obfuscate what you're actually trying to say.

@fuzzymo
Copy link

fuzzymo commented Aug 2, 2021 •
edited
Loading

I'm a bit late to the conversation here but I did want to chime in. As someone who is neurodivergent (autistic and ADHDer) and has dealt with mental health issues (both my own and those I care about), I agree about "sanity check." I am less sure about "reality check" but I certainly get why it should be avoided.

However, I don't agree with "health check." It is not singling out individuals or groups. The idea (maybe just to me) is that a health check is a holistic view of the "organism." Just as one should go to their primary doctors regularly to get check-ups (blood work, eye tests, hearing, dental, etc), a "health check" is meant to look for parts of the organism that need help/attention to be able to carry out their intended purpose effectively. It has been applied a bit more broadly than is needed, I will grant that.

@tzoor-rozental
Copy link

tzoor-rozental commented Aug 23, 2021 •
edited
Loading

very late to the party, but still relevant 4 years later.

my suggestions in order of preference:

  1. happy/sound tests - implies the functionality under test is only used correctly
  2. main/primary tests - implies the functionality under test is the most important
  3. basic/rudimentary tests - implies the functionality under test is the most simple (to use/test/understand)
  4. core/essential tests - implies the functionality under test is mandatory for the program to work

we can combine happy with the other three, creating:

  1. happy main tests - implies the functionality under test only considers correct usage of the most important functionality.
  2. happy basic tests - implies the functionality under test only considers correct usage of the most simple to use functionality.
  3. happy core tests - implies the functionality under test only considers correct usage of the functionality that is mandatory for the program to work.

combining any of main, basic, and core with each other might make sense, but I couldn't think of a useful combination.

IMO, sanity check is a very loaded term that can have very different meanings for different people, teams, and companies, and that is only considering the professional interpretation, rather than the mental health interpretation. as such, I think we can be more accurate and use other terms that better define our goals in testing. the terms I suggested can express slightly different things and can even be used together to describe intentions more accurately.

in the context of math, a sanity check is a basic test to quickly evaluate whether a claim or the result of a calculation can possibly be true.

in the context of programming, a sanity check is a very brief run-through of the functionality of a computer program, system, calculation, or other analysis, to assure that part of the system or methodology works roughly as expected, which is a slightly different meaning.

to the best of my knowledge, sanity testing roughly means testing the happy path of the basic functionality. it is more comprehensive than smoke testing and less comprehensive than other types of testing.

so the general escalation of the testing suites is as such:

  1. smoke testing: see if you can start using it.
  2. sanity tests happy testing: see you can use it correctly.
  3. ...more comprehensive or focused tests.

also, if we want to contrast happy to express tests that check incorrect usage, we might use sad, but shouldn't really because happy stems from happy path, and sad path is not a generally used term in the industry, so perhaps we can use faulty? but that's out of bound for this discussion. maybe next time.

that's all from me. I truly wish this highly important topic will get the attention it deserves. let's talk about it some more!

@tzoor-rozental
Copy link

another suggestion:
sanity foundations test
this might align more closely with the original intent of the phrase sanity check, which is to see you are operating under an acceptable frame of mind. but I feel it diverges a bit from the contemporary meaning, which is to see that the simplest stuff works to justify escalating to more complex testing suites.

@jesslark
Copy link

I've been trying to replace "sanity check" in my own vocabulary for a while. I really appreciate this discussion.

What are we really saying when we suggest our code needs a "sanity check"? It seems like we are saying that we have a set of assumptions about the code, and we are wanting to verify that those assumptions are correct. So what if we say more specifically what we mean?

"Can you do a quick assumptions check on that?"
"I am verifying my assumptions, the PR should be ready soon."

Assumptions check
Verify assumptions

@jonnysmith1981
Copy link

I agree with the sentiment here but, for the same reasons mentioned in the initial gist, I would be loathed to use a lot of the synonyms suggested, including:

  • Stability
  • Coherence
  • Confidence
  • Rationality

The antonyms of these words carry just as much negativity and (mostly) unintended ableism as "sanity".

@tzoor-rozental
Copy link

I have two more suggestions.

  • preliminary tests
  • base tests

both can expresses the same sentiment as sanity in a clearer more direct manner, and to the best of my knowledge without any baggage associated with them. personally I prefer "base" solely because it is a shorter word but I think either will be better than "sanity" at least.

@elsandosgrande
Copy link

I'd say that a good substitute is “integrity verification”.

@GeoGriffin
Copy link

MVP (minimum viable product) is used in describing features for a product. Could this be used for this sort of basic testing?
MVP Test would check minimum viable functionality for a product. Can we connect to the endpoints for a service. Does the service connect to the database or other external resources. Does the home screen display for a UI application.

@ghostal
Copy link

ghostal commented Mar 2, 2023 •
edited
Loading

It seems to me that most of the examples where things fall into potentially ableist or discriminatory language are also examples where a word has been used that isn't actually accurately describing what we're testing.

Many describe when we're testing (e.g. initial, preliminary), or the category of testing (e.g. essential), or how the tests sit in relation to other groups of tests (base, foundation, core, primary), or or how the tests make us feel (e.g. confidence, reliability), or uses some other metaphor (smoke).

(In my opinion, metaphors are the riskiest ground - not only do they drag a lot of unrelated, potentially discriminatory contextual baggage into the fray, but they're also often culture-specific. Non-native speakers of the language can easily be confused and alienated by them.)

To quote @seanmhanson 's original gist, "What am I actually checking?"

What are we considering to be "good" or "bad"?

Unfortunately, very few suggestions actually address this question - they're just vaguely defined taxonomies, or worse. There's logic there, yes, but they're all opaque in terms of the "what", and some really need to be explained, which would definitely have a negative impact on adoption.

@lychaxo suggests bounds check, which is a great example. We're checking that the result falls within some specified bounds. There's little ambiguity here.

More general thoughts...

It's interesting to see in these posts that some words which, on face value, appear to be less ableist (e.g. coherence) have been pointed out by others as in fact being potentially more problematic.

@pelevesque mentioned "sanitize", which actually (I assume) derives most recently from "sanitation", not "sanity", but nevertheless, both words derive from "sanus", the Latin for "healthy" (or so Google tells me - I'm no linguist). So maybe the word "sanitation" (as in, taking waste away from people for the purposes of avoiding disease, something I think we can all agree is a good thing) is out? How do we decide?

@lychaxo also mentions "valid"/"invalid" terminology, which seems to have come the Latin words for "strong", the word "invalidus" meaning "not strong", so I would guess this is the root of the ableist/discriminatory sense of the word. At some point at least several hundred years ago it seems it also began being applied legal/academic arguments.

Ultimately I find myself wondering how easy it is to steer clear of words that could be construed as ableist or discriminatory, given that so many words in modern language are derived from much older languages, the users/makers of which apparently had far fewer qualms about being discriminatory. Many of the things we want to describe, particularly in terms of testing, necessarily fall into the general categories of either "good" or "bad", and so very quickly we start down this slippery lingual slope towards discrimination. Even the word "discriminate", in another sense, can describe what happens in a test. We want to discriminate between wanted and unwanted outcomes.

I don't know where the line can be drawn. How long ago can a word change its meaning before it's okay to use it without having to consider the implications of a previous meaning? What about reclaimed words?

This probably seems like an unnecessary exercise in derailing the original conversation, presenting more difficult questions than answers (which is why I added a subheading before these thoughts, to separate them from more actionable suggestions above). But the point I'm making is that if we want to be successful at replacing pervasive discriminatory language in the tech world, and not be accused by people on all sides of being misguided/white knighting/babying others, etc, there's little point in randomly presenting ideas that are arguably "just as bad". We need to present better ideas. And for that we need some rubric to measure what "better" means. I don't know if that's possible, but I'd be interested if anyone more qualified than me has any thoughts to offer on this, or who can perhaps point us to some resources that aren't just more "instead of word X, use word Y".

@icywolfy
Copy link

icywolfy commented Mar 21, 2023 •
edited
Loading

@ghostal > mentioned "sanitize", which actually (I assume) derives most recently from "sanitation", not "sanity".

Correct.

Sanity => Sane (latin sanus = health) + ity.
Sanitize => Sane + ity + ize
Sanitary => Sane + ity + ary
Sanitation => Sane + ity + ary + tion.

They all come directly from the concept of sane "Health(y)".

@seanmhanson
Copy link
Author

seanmhanson commented Mar 21, 2023 via email

@pelevesque
Copy link

pelevesque commented Mar 29, 2023 via email

@slodaniel
Copy link

Alignment check? (Found this article by searching for alternatives to "sanity" and while the suggestions are good, they pointed me to "alignment" which is closer to the meaning I was looking for in my case.)

@pelevesque
Copy link

pelevesque commented Apr 17, 2023 via email

@tzoor-rozental
Copy link

it might help to define more concisely what we mean by the term sanity tests.

i understand sanity testing as checking that the bug fixes of the last build actually fix the bugs.

as such, sanity testing is a sub field of regression testing.

we can just use the term regression testing and lose the granularity.

but if we think about what we are actually doing in these tests, pehaps it can be beneficial to refer to the scope of the test instead.

so in this case, instead of sanity tests that verify a build, we can call these build tests, or my peraonal preference, delta tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment