Jump to content
Main menu
Main menu
move to sidebar
hide
Navigation
Main page
Recent changes
Random page
Help about MediaWiki
Special pages
Niidae Wiki
Search
Search
Appearance
Create account
Log in
Personal tools
Create account
Log in
Pages for logged out editors
learn more
Contributions
Talk
Editing
Sanity check
(section)
Page
Discussion
English
Read
Edit
View history
Tools
Tools
move to sidebar
hide
Actions
Read
Edit
View history
General
What links here
Related changes
Page information
Appearance
move to sidebar
hide
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
===Software development=== {{see|Smoke testing (software)}} In software development, a sanity test (a form of [[software testing]] which offers "quick, broad, and shallow testing"<ref>{{Cite journal |last1=Fecko |first1=Mariusz A. |last2=Lott |first2=Christopher M. |date=October 2002 |title=Lessons learned from automating tests for an operations support system |url=http://www.chris-lott.org/work/pubs/2002-spe.pdf |journal=Software: Practice and Experience |volume=32 |issue=15 |pages=1485–1506 |doi=10.1002/spe.491 |s2cid=16820529 |archive-url=https://web.archive.org/web/20030717041855/http://www.chris-lott.org/work/pubs/2002-spe.pdf |archive-date=17 July 2003}}</ref>) evaluates the result of a subset of application functionality to determine whether it is possible and reasonable to proceed with further testing of the entire application.<ref>{{Cite book |last1=Sammi |first1=Rabia |last2=Masood |first2=Iram |last3=Jabeen |first3=Shunaila |chapter=A Framework to Assure the Quality of Sanity Check Process |date=2011 |editor-last=Zain |editor-first=Jasni Mohamad |editor2-last=Wan Mohd |editor2-first=Wan Maseri bt |editor3-last=El-Qawasmeh |editor3-first=Eyas |title=Software Engineering and Computer Systems |series=Communications in Computer and Information Science |location=Berlin, Heidelberg |publisher=Springer |volume=181 |pages=143–150 |doi=10.1007/978-3-642-22203-0_13 |isbn=978-3-642-22203-0}}</ref> Sanity tests may sometimes be used interchangeably with [[smoke testing (software)|smoke tests]]<ref>ISTQB® Glossary for the International Software Testing Qualification Board® software testing qualification scheme, [https://www.istqb.org/downloads/glossary.html ISTQB Glossary] International Software Testing Qualification Board</ref> insofar as both terms denote tests which determine whether it is ''possible'' and ''reasonable'' to continue testing further. On the other hand, a distinction is sometimes made that a smoke test is a non-exhaustive test that ascertains whether the most crucial functions of a programme work before proceeding with further testing whereas a sanity test refers to whether specific functionality such as a particular bug fix works as expected without testing the wider functionality of the software.{{citation needed|date=January 2021}} In other words, a sanity test determines whether the intended result of a code change works correctly while a smoke test ensures that nothing else important was broken in the process. Sanity testing and smoke testing avoid wasting time and effort by quickly determining whether an application is too flawed to merit more rigorous [[Software quality assurance|QA testing]], but needs more developer [[debugging]]. Groups of sanity tests are often bundled together for automated [[unit testing]] of functions, libraries, or applications prior to [[Merge (version control)|merging]] development code into a testing or [[Trunk (software)|trunk]] version control [[Branching (version control)|branch]],<ref>{{cite journal | last = Jørgensen | first = Niels | doi = 10.1046/J.1365-2575.2001.00113.X | issue = 4 | journal = Information Systems Journal | page = 321 | title = Putting it all in the trunk: incremental software development in the FreeBSD open source project | url = https://webhotel4.ruc.dk/~nielsj/research/publications/freebsd.pdf | volume = 11 | year = 2001}}</ref> for [[Build automation|automated building]],<ref>Hassan, A. E. and Zhang, K. 2006. [http://portal.acm.org/citation.cfm?id=1169218.1169318&coll=&dl=ACM&type=series&idx=SERIES10803&part=series&WantType=Proceedings&title=ASE# Using Decision Trees to Predict the Certification Result of a Build]. In ''Proceedings of the 21st IEEE/ACM international Conference on Automated Software Engineering'' (September 18 – 22, 2006). Automated Software Engineering. IEEE Computer Society, Washington, DC, 189–198.</ref> or for [[continuous integration]] and [[continuous deployment]].<ref>{{cite journal | last1 = Chasidim | first1 = Hadas | last2 = Almog | first2 = Dani | last3 = Sohacheski | first3 = Dov Benyomin | last4 = Gillenson | first4 = Mark Lee | last5 = Poston | first5 = Robin S. | last6 = Mark | first6 = Shlomo | issue = 2 | journal = Journal of Information Technology Management | pages = 40–54 | title = The Unit Test: Facing CICD - Are They Elusive Definitions? | url = https://jitm.ubalt.edu/XXIX-2/article4.pdf | volume = 29 | year = 2018}}</ref> Another common usage of ''sanity test'' is to denote checks which are performed {{em|within}} programme code, usually on arguments to functions or returns therefrom, to see if the answers can be assumed to be correct. The more complicated the routine, the more important that its response be checked. The trivial case is checking to see whether the [[Return statement|return value]] of a function indicated success or failure, and to therefore cease further processing upon failure. This return value is actually often itself the result of a sanity check. For example, if the function attempted to open, write to, and close a file, a sanity check may be used to ensure that it did not fail on any of these actions—which is a sanity check often ignored by programmers.<ref>{{Cite book |last=Darwin |first=Ian F. |url=https://books.google.com/books?id=vweTteq3OLQC&pg=PA19 |title=Checking C programs with lint |date=January 1991 |publisher=O'Reilly & Associates |isbn=0-937175-30-7 |edition=1st ed., with minor revisions. |location=Newton, Mass. |page=19 |quote=A common programming habit is to ignore the return value from fprintf(stderr, ... |access-date=7 October 2014}}</ref> These kinds of sanity checks may be used during development for debugging purposes and also to aid in [[troubleshooting]] software [[Runtime (program lifecycle phase)|runtime errors]]. For example, in a bank account management application, a sanity check will fail if a withdrawal requests more money than the total account balance rather than allowing the account to go negative (which wouldn't be sane). Another sanity test might be that deposits or purchases correspond to patterns established by historical data—for example, large purchase transactions or ATM withdrawals in foreign locations never before visited by the cardholder may be flagged for confirmation.{{citation needed|date=January 2021}} Sanity checks are also performed upon installation of [[Software release life cycle|stable, production]] software code into a new computing [[Runtime system|environment]] to ensure that all [[Coupling (computer programming)|dependencies]] are met, such as a compatible [[operating system]] and [[Linker (computing)|link]] [[Library (computing)|libraries]]. When a computing environment has passed all the sanity checks, it's known as a sane environment for the installation programme to proceed with reasonable expectation of success. A [["Hello, World!" program]] is often used as a sanity test for a [[Deployment environment#Development|development environment]] similarly. Rather than a complicated script running a set of unit tests, if this simple programme fails to compile or execute, it proves that the supporting environment likely has a configuration problem that will prevent ''any'' code from compiling or executing. But if "Hello world" executes, then any problems experienced with other programmes likely can be attributed to errors in that application's code rather than the environment. The [[Association for Computing Machinery]],<ref>{{cite web|date=2020-11-20|access-date=2023-06-29|url=https://www.acm.org/diversity-inclusion/words-matter|title=Words Matter}}</ref> and software projects such as [[Android (operating system)|Android]],<ref>{{Cite web |date=2022-11-16 |title=Coding with respect |url=https://source.android.com/docs/setup/contribute/respectful-code |access-date=2023-01-23 |website=Android Open Source Project |language=en}}</ref> [[MediaWiki]]<ref>{{Cite web |title=Inclusive language/en-gb - MediaWiki |url=https://www.mediawiki.org/wiki/Inclusive_language/en-gb |access-date=2023-01-23 |website=www.mediawiki.org |language=en}}</ref> and [[Twitter]],<ref>{{Cite web |title=Twitter Engineering|url=https://twitter.com/twittereng/status/1278733305190342656 |access-date=2023-01-23 |website=Twitter |language=en-GB}}</ref> discourage use of the phrase ''sanity check'' in favour of other terms such as ''confidence test'', ''coherence check'', or simply ''test'', as part of a wider attempt to avoid [[ableist]] language and increase [[Inclusion (disability rights)|inclusivity]].
Summary:
Please note that all contributions to Niidae Wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see
Encyclopedia:Copyrights
for details).
Do not submit copyrighted work without permission!
Cancel
Editing help
(opens in new window)
Search
Search
Editing
Sanity check
(section)
Add topic