{"id":13495229,"url":"https://github.com/kward/shunit2","last_synced_at":"2025-05-14T04:09:28.102Z","repository":{"id":34225426,"uuid":"38091119","full_name":"kward/shunit2","owner":"kward","description":"shUnit2 is a xUnit based unit test framework for Bourne based shell scripts.","archived":false,"fork":false,"pushed_at":"2025-04-15T10:14:13.000Z","size":795,"stargazers_count":1661,"open_issues_count":43,"forks_count":206,"subscribers_count":49,"default_branch":"master","last_synced_at":"2025-05-12T09:24:30.005Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":"","language":"Shell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/kward.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":"CODE_OF_CONDUCT.md","threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2015-06-26T04:44:52.000Z","updated_at":"2025-05-08T09:15:45.000Z","dependencies_parsed_at":"2024-01-03T04:12:55.266Z","dependency_job_id":"f495c3f5-7ab4-4d55-a651-4dabf8ebfa0a","html_url":"https://github.com/kward/shunit2","commit_stats":{"total_commits":558,"total_committers":30,"mean_commits":18.6,"dds":"0.37275985663082434","last_synced_commit":"100ffe4dda539ebbe4ae9867132f08eeee8e80cb"},"previous_names":[],"tags_count":5,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kward%2Fshunit2","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kward%2Fshunit2/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kward%2Fshunit2/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/kward%2Fshunit2/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/kward","download_url":"https://codeload.github.com/kward/shunit2/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":254070107,"owners_count":22009559,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-07-31T19:01:32.749Z","updated_at":"2025-05-14T04:09:23.086Z","avatar_url":"https://github.com/kward.png","language":"Shell","readme":"# shUnit2\n\nshUnit2 is a [xUnit](http://en.wikipedia.org/wiki/XUnit) unit test framework for\nBourne based shell scripts, and it is designed to work in a similar manner to\n[JUnit](http://www.junit.org), [PyUnit](http://pyunit.sourceforge.net), etc.. If\nyou have ever had the desire to write a unit test for a shell script, shUnit2\ncan do the job.\n\n[![Travis CI](https://api.travis-ci.com/kward/shunit2.svg)](https://app.travis-ci.com/github/kward/shunit2)\n\n## Table of Contents\n\n* [Introduction](#introduction)\n  * [Credits / Contributors](#credits-contributors)\n  * [Feedback](#feedback)\n* [Quickstart](#quickstart)\n* [Function Reference](#function-reference)\n  * [General Info](#general-info)\n  * [Asserts](#asserts)\n  * [Failures](#failures)\n  * [Setup/Teardown](#setup-teardown)\n  * [Skipping](#skipping)\n  * [Suites](#suites)\n* [Advanced Usage](#advanced-usage)\n  * [Some constants you can use](#some-constants-you-can-use)\n  * [Error Handling](#error-handling)\n  * [Including Line Numbers in Asserts (Macros)](#including-line-numbers-in-asserts-macros)\n  * [Test Skipping](#test-skipping)\n  * [Running specific tests from the command line](#cmd-line-args)\n  * [Generating test results in JUnit format](#junit-reports)\n* [Appendix](#appendix)\n  * [Getting help](#getting-help)\n  * [Zsh](#zsh)\n\n---\n\n## \u003ca name=\"introduction\"\u003e\u003c/a\u003e Introduction\n\nshUnit2 was originally developed to provide a consistent testing solution for\n[log4sh][log4sh], a shell based logging framework similar to\n[log4j](http://logging.apache.org). During the development of that product, a\nrepeated problem of having things work just fine under one shell (`/bin/bash` on\nLinux to be specific), and then not working under another shell (`/bin/sh` on\nSolaris) kept coming up. Although several simple tests were run, they were not\nadequate and did not catch some corner cases. The decision was finally made to\nwrite a proper unit test framework after multiple brown-bag releases were made.\n_Research was done to look for an existing product that met the testing\nrequirements, but no adequate product was found._\n\n### Tested software\n\n**Tested Operating Systems** (varies over time)\n\nOS                                  | Support   | Verified\n----------------------------------- | --------- | --------\nUbuntu Linux (14.04.05 LTS)         | Travis CI | continuous\nmacOS High Sierra (10.13.3)         | Travis CI | continuous\nFreeBSD                             | user      | unknown\nSolaris 8, 9, 10 (inc. OpenSolaris) | user      | unknown\nCygwin                              | user      | unknown\n\n**Tested Shells**\n\n* Bourne Shell (__sh__)\n* BASH - GNU Bourne Again SHell (__bash__)\n* DASH - Debian Almquist Shell (__dash__)\n* Korn Shell - AT\u0026T version of the Korn shell (__ksh__)\n* mksh - MirBSD Korn Shell (__mksh__)\n* zsh - Zsh (__zsh__) (since 2.1.2) _please see the Zsh shell errata for more information_\n\nSee the appropriate Release Notes for this release\n(`doc/RELEASE_NOTES-X.X.X.txt`) for the list of actual versions tested.\n\n### \u003ca name=\"credits-contributors\"\u003e\u003c/a\u003e Credits / Contributors\n\nA list of contributors to shUnit2 can be found in `doc/contributors.md`. Many\nthanks go out to all those who have contributed to make this a better tool.\n\nshUnit2 is the original product of many hours of work by Kate Ward, the primary\nauthor of the code. For related software, check out https://github.com/kward.\n\n### \u003ca name=\"feedback\"\u003e\u003c/a\u003e Feedback\n\nFeedback is most certainly welcome for this document. Send your questions,\ncomments, and criticisms via the\n[shunit2-users](https://groups.google.com/a/forestent.com/forum/#!forum/shunit2-users/new)\nforum (created 2018-12-09), or file an issue via\nhttps://github.com/kward/shunit2/issues.\n\n---\n\n## \u003ca name=\"quickstart\"\u003e\u003c/a\u003e Quickstart\n\nThis section will give a very quick start to running unit tests with shUnit2.\nMore information is located in later sections.\n\nHere is a quick sample script to show how easy it is to write a unit test in\nshell. _Note: the script as it stands expects that you are running it from the\n\"examples\" directory._\n\n```sh\n#! /bin/sh\n# file: examples/equality_test.sh\n\ntestEquality() {\n  assertEquals 1 1\n}\n\n# Load shUnit2.\n. ../shunit2\n```\n\nRunning the unit test should give results similar to the following.\n\n```console\n$ cd examples\n$ ./equality_test.sh\ntestEquality\n\nRan 1 test.\n\nOK\n```\n\nW00t! You've just run your first successful unit test. So, what just happened?\nQuite a bit really, and it all happened simply by sourcing the `shunit2`\nlibrary. The basic functionality for the script above goes like this:\n\n* When shUnit2 is sourced, it will walk through any functions defined whose name\n  starts with the string `test`, and add those to an internal list of tests to\n  execute. Once a list of test functions to be run has been determined, shunit2\n  will go to work.\n* Before any tests are executed, shUnit2 again looks for a function, this time\n  one named `oneTimeSetUp()`. If it exists, it will be run. This function is\n  normally used to setup the environment for all tests to be run. Things like\n  creating directories for output or setting environment variables are good to\n  place here. Just so you know, you can also declare a corresponding function\n  named `oneTimeTearDown()` function that does the same thing, but once all the\n  tests have been completed. It is good for removing temporary directories, etc.\n* shUnit2 is now ready to run tests. Before doing so though, it again looks for\n  another function that might be declared, one named `setUp()`. If the function\n  exists, it will be run before each test. It is good for resetting the\n  environment so that each test starts with a clean slate. **At this stage, the\n  first test is finally run.** The success of the test is recorded for a report\n  that will be generated later. After the test is run, shUnit2 looks for a final\n  function that might be declared, one named `tearDown()`. If it exists, it will\n  be run after each test. It is a good place for cleaning up after each test,\n  maybe doing things like removing files that were created, or removing\n  directories. This set of steps, `setUp() \u003e test() \u003e tearDown()`, is repeated\n  for all of the available tests.\n* Once all the work is done, shUnit2 will generate the nice report you saw\n  above. A summary of all the successes and failures will be given so that you\n  know how well your code is doing.\n\nWe should now try adding a test that fails. Change your unit test to look like\nthis.\n\n```sh\n#! /bin/sh\n# file: examples/party_test.sh\n\ntestEquality() {\n  assertEquals 1 1\n}\n\ntestPartyLikeItIs1999() {\n  year=`date '+%Y'`\n  assertEquals \"It's not 1999 :-(\" '1999' \"${year}\"\n}\n\n# Load shUnit2.\n. ../shunit2\n```\n\nSo, what did you get? I guess it told you that this isn't 1999. Bummer, eh?\nHopefully, you noticed a couple of things that were different about the second\ntest. First, we added an optional message that the user will see if the assert\nfails. Second, we did comparisons of strings instead of integers as in the first\ntest. It doesn't matter whether you are testing for equality of strings or\nintegers. Both work equally well with shUnit2.\n\nHopefully, this is enough to get you started with unit testing. If you want a\nton more examples, take a look at the tests provided with [log4sh][log4sh] or\n[shFlags][shflags]. Both provide excellent examples of more advanced usage.\nshUnit2 was after all written to meet the unit testing need that\n[log4sh][log4sh] had.\n\nIf you are using distribution packaged shUnit2 which is accessible from\n`/usr/bin/shunit2` such as Debian, you can load shUnit2 without specifying its\npath.  So the last 2 lines in the above can be replaced by:\n\n```sh\n# Load shUnit2.\n. shunit2\n```\n\n---\n\n## \u003ca name=\"function-reference\"\u003e\u003c/a\u003e Function Reference\n\n### \u003ca name=\"general-info\"\u003e\u003c/a\u003e General Info\n\nAny string values passed should be properly quoted -- they should be\nsurrounded by single-quote (`'`) or double-quote (`\"`) characters -- so that the\nshell will properly parse them.\n\n### \u003ca name=\"asserts\"\u003e\u003c/a\u003e Asserts\n\n    assertEquals [message] expected actual\n\nAsserts that _expected_ and _actual_ are equal to one another. The _expected_\nand _actual_ values can be either strings or integer values as both will be\ntreated as strings. The _message_ is optional, and must be quoted.\n\n    assertNotEquals [message] unexpected actual\n\nAsserts that _unexpected_ and _actual_ are not equal to one another. The\n_unexpected_ and _actual_ values can be either strings or integer values as both\nwill be treated as strings. The _message_ is optional, and must be quoted.\n\n    assertSame [message] expected actual\n\nThis function is functionally equivalent to `assertEquals`.\n\n    assertNotSame [message] unexpected actual\n\nThis function is functionally equivalent to `assertNotEquals`.\n\n    assertContains [message] container content\n\nAsserts that _container_ contains _content_. The _container_ and _content_\nvalues can be either strings or integer values as both will be treated as\nstrings. The _message_ is optional, and must be quoted.\n\n    assertNotContains [message] container content\n\nAsserts that _container_ does not contain _content_. The _container_ and\n_content_ values can be either strings or integer values as both will be treated\nas strings. The _message_ is optional, and must be quoted.\n\n    assertNull [message] value\n\nAsserts that _value_ is _null_, or in shell terms, a zero-length string. The\n_value_ must be a string as an integer value does not translate into a zero-\nlength string. The _message_ is optional, and must be quoted.\n\n    assertNotNull [message] value\n\nAsserts that _value_ is _not null_, or in shell terms, a non-empty string. The\n_value_ may be a string or an integer as the latter will be parsed as a non-empty\nstring value. The _message_ is optional, and must be quoted.\n\n    assertTrue [message] condition\n\nAsserts that a given shell test _condition_ is _true_. The condition can be as\nsimple as a shell _true_ value (the value `0` -- equivalent to\n`${SHUNIT_TRUE}`), or a more sophisticated shell conditional expression. The\n_message_ is optional, and must be quoted.\n\nA sophisticated shell conditional expression is equivalent to what the __if__ or\n__while__ shell built-ins would use (more specifically, what the __test__\ncommand would use). Testing for example whether some value is greater than\nanother value can be done this way.\n\n    assertTrue \"[ 34 -gt 23 ]\"\n\nTesting for the ability to read a file can also be done. This particular test\nwill fail.\n\n    assertTrue 'test failed' \"[ -r /some/non-existant/file ]\"\n\nAs the expressions are standard shell __test__ expressions, it is possible to\nstring multiple expressions together with `-a` and `-o` in the standard fashion.\nThis test will succeed as the entire expression evaluates to _true_.\n\n    assertTrue 'test failed' '[ 1 -eq 1 -a 2 -eq 2 ]'\n\n\u003ci\u003eOne word of warning: be very careful with your quoting as shell is not the\nmost forgiving of bad quoting, and things will fail in strange ways.\u003c/i\u003e\n\n    assertFalse [message] condition\n\nAsserts that a given shell test _condition_ is _false_. The condition can be as\nsimple as a shell _false_ value (the value `1` -- equivalent to\n`${SHUNIT_FALSE}`), or a more sophisticated shell conditional expression. The\n_message_ is optional, and must be quoted.\n\n_For examples of more sophisticated expressions, see `assertTrue`._\n\n### \u003ca name=\"failures\"\u003e\u003c/a\u003e Failures\n\nJust to clarify, failures __do not__ test the various arguments against one\nanother. Failures simply fail, optionally with a message, and that is all they\ndo. If you need to test arguments against one another, use asserts.\n\nIf all failures do is fail, why might one use them? There are times when you may\nhave some very complicated logic that you need to test, and the simple asserts\nprovided are simply not adequate. You can do your own validation of the code,\nuse an `assertTrue ${SHUNIT_TRUE}` if your own tests succeeded, and use a\nfailure to record a failure.\n\n    fail [message]\n\nFails the test immediately. The _message_ is optional, and must be quoted.\n\n    failNotEquals [message] unexpected actual\n\nFails the test immediately, reporting that the _unexpected_ and _actual_ values\nare not equal to one another. The _message_ is optional, and must be quoted.\n\n_Note: no actual comparison of unexpected and actual is done._\n\n    failSame [message] expected actual\n\nFails the test immediately, reporting that the _expected_ and _actual_ values\nare the same. The _message_ is optional, and must be quoted.\n\n_Note: no actual comparison of expected and actual is done._\n\n    failNotSame [message] expected actual\n\nFails the test immediately, reporting that the _expected_ and _actual_ values\nare not the same. The _message_ is optional, and must be quoted.\n\n_Note: no actual comparison of expected and actual is done._\n\n    failFound [message] content\n\nFails the test immediately, reporting that the _content_ was found. The\n_message_ is optional, and must be quoted.\n\n_Note: no actual search of content is done._\n\n    failNotFound [message] content\n\nFails the test immediately, reporting that the _content_ was not found. The\n_message_ is optional, and must be quoted.\n\n_Note: no actual search of content is done._\n\n### \u003ca name=\"setup-teardown\"\u003e\u003c/a\u003e Setup/Teardown\n\n    oneTimeSetUp\n\nThis function can be optionally overridden by the user in their test suite.\n\nIf this function exists, it will be called once before any tests are run. It is\nuseful to prepare a common environment for all tests.\n\n    oneTimeTearDown\n\nThis function can be optionally overridden by the user in their test suite.\n\nIf this function exists, it will be called once after all tests are completed.\nIt is useful to clean up the environment after all tests.\n\n    setUp\n\nThis function can be optionally overridden by the user in their test suite.\n\nIf this function exists, it will be called before each test is run. It is useful\nto reset the environment before each test.\n\n    tearDown\n\nThis function can be optionally overridden by the user in their test suite.\n\nIf this function exists, it will be called after each test completes. It is\nuseful to clean up the environment after each test.\n\n### \u003ca name=\"skipping\"\u003e\u003c/a\u003e Skipping\n\n    startSkipping\n\nThis function forces the remaining _assert_ and _fail_ functions to be\n\"skipped\", i.e. they will have no effect. Each function skipped will be recorded\nso that the total of asserts and fails will not be altered.\n\n    endSkipping\n\nThis function returns calls to the _assert_ and _fail_ functions to their\ndefault behavior, i.e. they will be called.\n\n    isSkipping\n\nThis function returns the current state of skipping. It can be compared against\n`${SHUNIT_TRUE}` or `${SHUNIT_FALSE}` if desired.\n\n### \u003ca name=\"suites\"\u003e\u003c/a\u003e Suites\n\nThe default behavior of shUnit2 is that all tests will be found dynamically. If\nyou have a specific set of tests you want to run, or you don't want to use the\nstandard naming scheme of prefixing your tests with `test`, these functions are\nfor you. Most users will never use them though.\n\n    suite\n\nThis function can be optionally overridden by the user in their test suite.\n\nIf this function exists, it will be called when `shunit2` is sourced. If it does\nnot exist, shUnit2 will search the parent script for all functions beginning\nwith the word `test`, and they will be added dynamically to the test suite.\n\n    suite_addTest name\n\nThis function adds a function named _name_ to the list of tests scheduled for\nexecution as part of this test suite. This function should only be called from\nwithin the `suite()` function.\n\n---\n\n## \u003ca name=\"advanced-usage\"\u003e\u003c/a\u003e Advanced Usage\n\n### \u003ca name=\"some-constants-you-can-use\"\u003e\u003c/a\u003e Some constants you can use\n\nThere are several constants provided by shUnit2 as variables that might be of\nuse to you.\n\n*Predefined*\n\n| Constant        | Value |\n| --------------- | ----- |\n| SHUNIT\\_TRUE    | Standard shell `true` value (the integer value 0). |\n| SHUNIT\\_FALSE   | Standard shell `false` value (the integer value 1). |\n| SHUNIT\\_ERROR   | The integer value 2. |\n| SHUNIT\\_TMPDIR  | Path to temporary directory that will be automatically cleaned up upon exit of shUnit2. |\n| SHUNIT\\_VERSION | The version of shUnit2 you are running. |\n\n*User defined*\n\n| Constant          | Value |\n| ----------------- | ----- |\n| SHUNIT\\_CMD\\_EXPR | Override which `expr` command is used. By default `expr` is used, except on BSD systems where `gexpr` is used. |\n| SHUNIT\\_COLOR     | Enable colorized output. Options are 'auto', 'always', or 'none', with 'auto' being the default. |\n| SHUNIT\\_PARENT    | The filename of the shell script containing the tests. This is needed specifically for Zsh support. |\n| SHUNIT\\_TEST\\_PREFIX | Define this variable to add a prefix in front of each test name that is output in the test report. |\n\n### \u003ca name=\"error-handling\"\u003e\u003c/a\u003e Error handling\n\nThe constants values `SHUNIT_TRUE`, `SHUNIT_FALSE`, and `SHUNIT_ERROR` are\nreturned from nearly every function to indicate the success or failure of the\nfunction. Additionally the variable `flags_error` is filled with a detailed\nerror message if any function returns with a `SHUNIT_ERROR` value.\n\n### \u003ca name=\"including-line-numbers-in-asserts-macros\"\u003e\u003c/a\u003e Including Line Numbers in Asserts (Macros)\n\nIf you include lots of assert statements in an individual test function, it can\nbecome difficult to determine exactly which assert was thrown unless your\nmessages are unique. To help somewhat, line numbers can be included in the\nassert messages. To enable this, a special shell \"macro\" must be used rather\nthan the standard assert calls. _Shell doesn't actually have macros; the name is\nused here as the operation is similar to a standard macro._\n\nFor example, to include line numbers for a `assertEquals()` function call,\nreplace the `assertEquals()` with `${_ASSERT_EQUALS_}`.\n\n_**Example** -- Asserts with and without line numbers_\n\n```shell\n#! /bin/sh\n# file: examples/lineno_test.sh\n\ntestLineNo() {\n  # This assert will have line numbers included (e.g. \"ASSERT:[123] ...\").\n  echo \"ae: ${_ASSERT_EQUALS_}\"\n  ${_ASSERT_EQUALS_} 'not equal' 1 2\n\n  # This assert will not have line numbers included (e.g. \"ASSERT: ...\").\n  assertEquals 'not equal' 1 2\n}\n\n# Load shUnit2.\n. ../shunit2\n```\n\nNotes:\n\n1. Due to how shell parses command-line arguments, _**all strings used with\n   macros should be quoted twice**_. Namely, single-quotes must be converted to single-double-quotes, and vice-versa.\u003cbr/\u003e\n   \u003cbr/\u003e\n   Normal `assertEquals` call.\u003cbr/\u003e\n   `assertEquals 'some message' 'x' ''`\u003cbr/\u003e\n   \u003cbr/\u003e\n   Macro `_ASSERT_EQUALS_` call. Note the extra quoting around the _message_ and\n   the _null_ value.\u003cbr/\u003e\n   `_ASSERT_EQUALS_ '\"some message\"' 'x' '\"\"'`\n\n1. Line numbers are not supported in all shells. If a shell does not support\n   them, no errors will be thrown. Supported shells include: __bash__ (\u003e=3.0),\n   __ksh__, __mksh__, and __zsh__.\n\n### \u003ca name=\"test-skipping\"\u003e\u003c/a\u003e Test Skipping\n\nThere are times where the test code you have written is just not applicable to\nthe system you are running on. This section describes how to skip these tests\nbut maintain the total test count.\n\nProbably the easiest example would be shell code that is meant to run under the\n__bash__ shell, but the unit test is running under the Bourne shell. There are\nthings that just won't work. The following test code demonstrates two sample\nfunctions, one that will be run under any shell, and the another that will run\nonly under the __bash__ shell.\n\n_**Example** -- math include_\n```sh\n# file: examples/math.inc.\n\nadd_generic() {\n  num_a=$1\n  num_b=$2\n\n  expr $1 + $2\n}\n\nadd_bash() {\n  num_a=$1\n  num_b=$2\n\n  echo $(($1 + $2))\n}\n```\n\nAnd here is a corresponding unit test that correctly skips the `add_bash()` function when the unit test is not running under the __bash__ shell.\n\n_**Example** -- math unit test_\n```sh\n#! /bin/sh\n# file: examples/math_test.sh\n\ntestAdding() {\n  result=`add_generic 1 2`\n  assertEquals \\\n      \"the result of '${result}' was wrong\" \\\n      3 \"${result}\"\n\n  # Disable non-generic tests.\n  [ -z \"${BASH_VERSION:-}\" ] \u0026\u0026 startSkipping\n\n  result=`add_bash 1 2`\n  assertEquals \\\n      \"the result of '${result}' was wrong\" \\\n      3 \"${result}\"\n}\n\noneTimeSetUp() {\n  # Load include to test.\n  . ./math.inc\n}\n\n# Load and run shUnit2.\n. ../shunit2\n```\n\nRunning the above test under the __bash__ shell will result in the following\noutput.\n\n```console\n$ /bin/bash math_test.sh\ntestAdding\n\nRan 1 test.\n\nOK\n```\n\nBut, running the test under any other Unix shell will result in the following\noutput.\n\n```console\n$ /bin/ksh math_test.sh\ntestAdding\n\nRan 1 test.\n\nOK (skipped=1)\n```\n\nAs you can see, the total number of tests has not changed, but the report\nindicates that some tests were skipped.\n\nSkipping can be controlled with the following functions: `startSkipping()`,\n`endSkipping()`, and `isSkipping()`. Once skipping is enabled, it will remain\nenabled until the end of the current test function call, after which skipping is\ndisabled.\n\n### \u003ca name=\"cmd-line-args\"\u003e\u003c/a\u003e Running specific tests from the command line.\n\nWhen running a test script, you may override the default set of tests, or the suite-specified set of tests, by providing additional arguments on the command line.  Each additional argument after the `--` marker is assumed to be the name of a test function to be run in the order specified.  e.g.\n\n```console\ntest-script.sh -- testOne testTwo otherFunction\n```\n\nor\n\n```console\nshunit2 test-script.sh testOne testTwo otherFunction\n```\n\nIn either case, three functions will be run as tests, `testOne`, `testTwo`, and `otherFunction`.  Note that the function `otherFunction` would not normally be run by `shunit2` as part of the implicit collection of tests as it's function name does not match the test function name pattern `test*`.\n\nIf a specified test function does not exist, `shunit2` will still attempt to run that function and thereby cause a failure which `shunit2` will catch and mark as a failed test.  All other tests will run normally.\n\nThe specification of tests does not affect how `shunit2` looks for and executes the setup and tear down functions, which will still run as expected.\n\n### \u003ca name=\"junit-reports\"\u003e\u003c/a\u003e Generating test results in JUnit format.\n\nMost continuous integration tools like CircleCI, are capable to interpret test results in JUnit format, helping you with spacilized sections and triggers tailored to identify faster a failing test. This functionality is still unreleased but you can test it right away, installing shunit2 from source.\n\nGiven that you execute your test script in the following way\n\n```sh\ntest-script.sh\n```\n\nYou can generate the JUnit report like this\n\n```sh\nmkdir -p results\ntest-script.sh -- --output-junit-xml=results/test-script.xml\n```\n\nIt will generate something like\n\n```xml\n\u003c?xml version=\"1.0\" encoding=\"UTF-8\"?\u003e\n\u003ctestsuite\n  failures=\"0\"\n  name=\"test-script.sh\"\n  tests=\"1\"\n  assertions=\"1\"\n\u003e\n  \u003ctestcase\n    classname=\"test-script.sh\"\n    name=\"testOne\"\n    assertions=\"1\"\n  \u003e\n  \u003c/testcase\u003e\n\u003c/testsuite\u003e\n```\n\nYou can also specify a more verbose suite name\n\n```sh\ntest-script.sh -- --output-junit-xml=results/test-script.xml --suite-name=Test_Script\n```\n\nThen say to your CI tool where the results are. In the case of CircleCI is like the following\n\n```yaml\n- store_test_results:\n    path: results\n```\n\n---\n\n## \u003ca name=\"appendix\"\u003e\u003c/a\u003e Appendix\n\n### \u003ca name=\"getting-help\"\u003e\u003c/a\u003e Getting Help\n\nFor help, please send requests to either the shunit2-users@forestent.com mailing\nlist (archives available on the web at\nhttps://groups.google.com/a/forestent.com/forum/#!forum/shunit2-users) or\ndirectly to Kate Ward \u003ckate dot ward at forestent dot com\u003e.\n\n### \u003ca name=\"zsh\"\u003e\u003c/a\u003e Zsh\n\nFor compatibility with Zsh, there is one requirement that must be met -- the\n`shwordsplit` option must be set. There are three ways to accomplish this.\n\n1. In the unit-test script, add the following shell code snippet before sourcing\n   the `shunit2` library.\n\n   ```sh\n   setopt shwordsplit\n   ```\n\n2. When invoking __zsh__ from either the command-line or as a script with `#!`,\n   add the `-y` parameter.\n\n    ```sh\n    #! /bin/zsh -y\n    ```\n\n3. When invoking __zsh__ from the command-line, add `-o shwordsplit --` as\n   parameters before the script name.\n\n   ```console\n   $ zsh -o shwordsplit -- some_script\n   ```\n\n[log4sh]: https://github.com/kward/log4sh\n[shflags]: https://github.com/kward/shflags\n","funding_links":[],"categories":["Shell","Applications","Shell Script Development"],"sub_categories":["Testing","Directory Navigation"],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fkward%2Fshunit2","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fkward%2Fshunit2","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fkward%2Fshunit2/lists"}