tests
This commit is contained in:
@@ -0,0 +1,3 @@
|
||||
{
|
||||
"MD024": { "siblings_only": true }
|
||||
}
|
||||
@@ -0,0 +1,574 @@
|
||||
# Changelog
|
||||
|
||||
All notable changes to this project will be documented in this file.
|
||||
|
||||
The format is based on [Keep a Changelog][kac] and this project adheres to
|
||||
[Semantic Versioning][semver].
|
||||
|
||||
[kac]: https://keepachangelog.com/en/1.0.0/
|
||||
[semver]: https://semver.org/
|
||||
|
||||
|
||||
## [Unreleased]
|
||||
|
||||
## [1.11.0] - 2024-03-24
|
||||
|
||||
### Added
|
||||
|
||||
* hardened CI scripts by using hashes instead of versions for actions and restricting permissions (#754, #770)
|
||||
* add security.md (#762)
|
||||
* add codespell CI checks (#720)
|
||||
* dynamic test registration via `bats_test_function` (#349)
|
||||
* add check that Bats is executed with Bash >= 3.2 (#873)
|
||||
|
||||
### Fixed
|
||||
|
||||
* `install.sh` now works for deviating `lib/` dirs (like `lib32`,`lib64`) (#487)
|
||||
* catch unset `BATS_TEST_SOURCE` in `lib/bats-core/tracing.bash` so
|
||||
`set -u`/`set -o nounset` works as expected (#827)
|
||||
* fix `--gather-test-outputs-in` fails on tests with multiple `/` (#789)
|
||||
* install does not create unused `/usr/share/bats` anymore (#857)
|
||||
* ensure IFS is unchanged in `{setup,teardown}{_suite,_file,}`, `@test` and free code (#879)
|
||||
* junit formatter: remove ANSI Codes to avoid invalid XML character (#886)
|
||||
|
||||
### Changed
|
||||
|
||||
* update Docker image with the latest `bats-file` version 0.4.0 (#780)
|
||||
* update Docker image with the latest `bats-detik` version 1.3.0 (#876)
|
||||
|
||||
#### Documentation
|
||||
|
||||
* clarify docker usage (#741)
|
||||
* update Arch Linux package URL in installation.rst (#821)
|
||||
* rename bash-bats to bats for Arch Linux in installation.rst (#836)
|
||||
* fix FAQ entry about setup-/teardown_suite, as they are available now (#861)
|
||||
* added logo (#881)
|
||||
|
||||
## [1.10.0] - 2023-07-15
|
||||
|
||||
### Added
|
||||
|
||||
* add `${BATS_TEST_TAGS[@]}` for querying the tags during a test (#705)
|
||||
* print tags on failing tests (#705)
|
||||
* test for negative arguments to `--jobs` (#693)
|
||||
* add tests for `--formatter cat` (#710)
|
||||
* test coverage in CI (#718)
|
||||
* Support for [rush](https://github.com/shenwei356/rush) as alternative to GNU parallel (#729)
|
||||
* add `bats_pipe` helper function for `run` that executes `\|` as pipes (#663)
|
||||
* publish docker images to ghcr.io (additionally to Dockerhub) (#740)
|
||||
|
||||
### Documentation
|
||||
|
||||
* clarify use cases of `--formatter cat` (#710)
|
||||
|
||||
### Fixed
|
||||
|
||||
* fix `run` with options overwriting the value of `i` (#726, #727)
|
||||
* fix `${BATS_TEST_NAMES[@]}` containing only `--tags` instead of test name since Bats v1.8.0 (#705)
|
||||
* fix `run --keep-empty-lines` counting trailing `\n` as (empty) new line (#711)
|
||||
* fix short flag unpacker creating bogus command lines with valued flags (#732)
|
||||
* fix formatter becoming confused with retries (#734)
|
||||
* fix `--gather-test-outputs-in` fails on tests with `/` (#735)
|
||||
* fix overriding `date` breaks `--timing` (#736)
|
||||
|
||||
#### Documentation
|
||||
|
||||
* typos, minor edits (#704)
|
||||
* simplified contributing.md (#718)
|
||||
|
||||
## [1.9.0] - 2023-02-12
|
||||
|
||||
### Added
|
||||
|
||||
* add installation instructions for Debian, Fedora, Gentoo, and OpenSUSE (#659)
|
||||
* add `--line-reference-format` to switch file/line references in stack traces (#665)
|
||||
* `comma_line` (default): `file.bats, line 1`
|
||||
* `colon`: `file.bats:1`
|
||||
* `uri`: `file:///path/to/file.bats:1`
|
||||
* `custom`: define your own formatter in `bats_format_file_line_reference_custom`
|
||||
* add `bats:focus` tag to run only focused tests (#679)
|
||||
* add bats-support, bats-assert, bats-file and bats-detik to Dockerfile (#674)
|
||||
|
||||
### Documentation
|
||||
|
||||
* add `--help` text and `man` page content for `--filter-tags` (#679)
|
||||
|
||||
### Fixed
|
||||
|
||||
* explicitly check for GNU parallel (#691)
|
||||
* wait for report-formatter to finish before ending `bats`' execution,
|
||||
to fix empty files with `--report-fomatter junit` under Docker (#692)
|
||||
|
||||
#### Documentation
|
||||
|
||||
* improved clarity of section about output in free code (#671)
|
||||
* fixed typos (#673)
|
||||
* clarify use cases of `run` (#366)
|
||||
|
||||
## [1.8.2] - 2022-10-19
|
||||
|
||||
### Fixed
|
||||
|
||||
* fix non zero return code on successful retried tests (#670)
|
||||
* fix `skip` in `setup_file` failing test suite (#687)
|
||||
|
||||
## [1.8.1] - 2022-10-19
|
||||
|
||||
### Fixed
|
||||
|
||||
* `shfmt` all files and enforce via CI (#651)
|
||||
* avoid kernel warning flood/hang with CTRL+C on Bash 5.2 RC (#656)
|
||||
* Fix infinite wait with (invalid) `-j<n>` (without space) (#657)
|
||||
|
||||
## [1.8.0] - 2022-09-15
|
||||
|
||||
### Added
|
||||
|
||||
* using external formatters via `--formatter <absolute path>` (also works for
|
||||
`--report-formatter`) (#602)
|
||||
* running only tests that failed in the last run via `--filter-status failed` (#483)
|
||||
* variable `BATS_TEST_RETRIES` that specifies how often a test should be
|
||||
reattempted before it is considered failed (#618)
|
||||
* Docker tags `latest-no-faccessat2` and `<bats-version\>-no-faccessat2` for
|
||||
avoiding `bash: bats: No such file or directory` on `docker<20.10` (or
|
||||
`runc<v1.0.0-rc93`) (#622)
|
||||
* `BATS_TEST_TIMEOUT` variable to force a timeout on test (including `setup()`) (#491)
|
||||
* also print (nonempty) `$stderr` (from `run --separate-stderr`) with
|
||||
`--print-output-on-failure` (#631)
|
||||
* `# bats test_tags=<tag list>`/`# bats file_tags=<tag list>` and
|
||||
`--filter-tags <tag list>` for tagging tests for execution filters (#642)
|
||||
* warning BW03: inform about `setup_suite` in wrong file (`.bats` instead of `setup_suite.bash`) (#652)
|
||||
|
||||
#### Documentation
|
||||
|
||||
* update gotcha about negated statements: Recommend using `run !` on Bats
|
||||
versions >=1.5.0 (#593)
|
||||
* add documentation for `bats_require_minimum_version` (#595)
|
||||
* improve documentation about `setup_suite` (#652)
|
||||
|
||||
### Fixed
|
||||
|
||||
* added missing shebang (#597)
|
||||
* remaining instances of `run -<N>` being incorrectly documented as `run =<N>` (#599)
|
||||
* allow `--gather-test-outputs-in <directory>` to work with existing, empty
|
||||
directories (#603)
|
||||
* also add `--clean-and-gather-test-outputs-in <directory>` for improved UX
|
||||
* double slashes in paths derived from TMPDIR on MacOS (#607)
|
||||
* fix `load` in `teardown` marking failed tests as not run (#612)
|
||||
* fix unset variable errors (with set -u) and add regression test (#621)
|
||||
* `teardown_file` errors don't swallow `setup_file` errors anymore, the behavior
|
||||
is more like `teardown`'s now (only `return`/last command can trigger `teardown`
|
||||
errors) (#623)
|
||||
* upgraded from deprecated CI envs for MacOS (10 -> 11,12) and Ubuntu
|
||||
(18.04 -> 22.04) (#630)
|
||||
* add `/usr/lib/bats` as default value for `BATS_LIB_PATH` (#628)
|
||||
* fix unset variable in `bats-formatter-junit` when `setup_file` fails (#632)
|
||||
* unify error behavior of `teardown`/`teardown_file`/`teardown_suite` functions:
|
||||
only fail via return code, not via ERREXIT (#633)
|
||||
* fix unbound variable errors with `set -u` on `setup_suite` failures (#643)
|
||||
* fix `load` not being available in `setup_suite` (#644)
|
||||
* fix RPM spec, add regression test (#648)
|
||||
* fix handling of `IFS` by `run` (#650)
|
||||
* only print `setup_suite`'s stderr on errors (#649)
|
||||
|
||||
#### Documentation
|
||||
|
||||
* fix typos, spelling and links (#596, #604, #619, #627)
|
||||
* fix redirection order of an example in the tutorial (#617)
|
||||
|
||||
## [1.7.0] - 2022-05-14
|
||||
|
||||
### Added
|
||||
|
||||
* Pretty formatter print filename when entering file (#561)
|
||||
* BATS_TEST_NAME_PREFIX allows prefixing test names on stdout and in reports (#561)
|
||||
* setup_suite and teardown_suite (#571, #585)
|
||||
* out-of-band warning infrastructure, with following warnings:
|
||||
* BW01: run command not found (exit code 127) (#586)
|
||||
* BW02: run uses flags without proper `bats_require_minimum_version` guard (#587)
|
||||
* `bats_require_minimum_version` to guard code that would not run on older
|
||||
versions (#587)
|
||||
|
||||
#### Documentation
|
||||
|
||||
* document `$BATS_VERSION` (#557)
|
||||
* document new warning infrastructure (#589, #587, #586)
|
||||
|
||||
### Fixed
|
||||
|
||||
* unbound variable errors in formatters when using `SHELLOPTS=nounset` (`-u`) (#558)
|
||||
* don't require `flock` *and* `shlock` for parallel mode test (#554)
|
||||
* print name of failing test when using TAP13 with timing information (#559, #555)
|
||||
* removed broken symlink, added regression test (#560)
|
||||
* don't show empty lines as `#` with pretty formatter (#561)
|
||||
* prevent `teardown`, `teardown_file`, and `teardown_suite` from overriding bats'
|
||||
exit code by setting `$status` (e.g. via calling `run`) (#581, #575)
|
||||
* **CRITICAL**: this can return exit code 0 despite failed tests, thus preventing
|
||||
your CI from reporting test failures! The regression happened in version 1.6.0.
|
||||
* `run --keep-empty-lines` now reports 0 lines on empty `$output` (#583)
|
||||
|
||||
#### Documentation
|
||||
|
||||
* remove 2018 in title, update copyright dates in README.md (#567)
|
||||
* fix broken links (#568)
|
||||
* corrected invalid documentation of `run -N` (had `=N` instead) (#579)
|
||||
* **CRITICAL**: using the incorrect form can lead to silent errors. See
|
||||
[issue #578](https://github.com/bats-core/bats-core/issues/578) for more
|
||||
details and how to find out if your tests are affected.
|
||||
|
||||
## [1.6.1] - 2022-05-14
|
||||
|
||||
### Fixed
|
||||
|
||||
* prevent `teardown`, `teardown_file`, and `teardown_suite` from overriding bats'
|
||||
exit code by setting `$status` (e.g. via calling `run`) (#581, #575)
|
||||
* **CRITICAL**: this can return exit code 0 despite failed tests, thus preventing
|
||||
your CI from reporting test failures! The regression happened in version 1.6.0.
|
||||
|
||||
#### Documentation
|
||||
|
||||
* corrected invalid documentation of `run -N` (had `=N` instead) (#579)
|
||||
* **CRITICAL**: using the incorrect form can lead to silent errors. See
|
||||
[issue #578](https://github.com/bats-core/bats-core/issues/578) for more
|
||||
details and how to find out if your tests are affected.
|
||||
|
||||
## [1.6.0] - 2022-02-24
|
||||
|
||||
### Added
|
||||
|
||||
* new flag `--code-quote-style` (and `$BATS_CODE_QUOTE_STYLE`) to customize
|
||||
quotes around code blocks in error output (#506)
|
||||
* an example/regression test for running background tasks without blocking the
|
||||
test run (#525, #535)
|
||||
* `bats_load_library` for loading libraries from the search path
|
||||
`$BATS_LIB_PATH` (#548)
|
||||
|
||||
### Fixed
|
||||
|
||||
* improved error trace for some broken cases (#279)
|
||||
* removed leftover debug file `/tmp/latch` in selftest suite
|
||||
(single use latch) (#516)
|
||||
* fix recurring errors on CTRL+C tests with NPM on Windows in selftest suite (#516)
|
||||
* fixed leaking of local variables from debug trap (#520)
|
||||
* don't mark FD3 output from `teardown_file` as `<failure>` in junit output (#532)
|
||||
* fix unbound variable error with Bash pre 4.4 (#550)
|
||||
|
||||
#### Documentation
|
||||
|
||||
* remove links to defunct freenode IRC channel (#515)
|
||||
* improved grammar (#534)
|
||||
* fixed link to TAP spec (#537)
|
||||
|
||||
## [1.5.0] - 2021-10-22
|
||||
|
||||
### Added
|
||||
|
||||
* new command line flags (#488)
|
||||
* `--verbose-run`: Make `run` print `$output` by default
|
||||
* `-x`, `--trace`: Print test commands as they are executed (like `set -x`)`
|
||||
* `--show-output-of-passing-tests`: Print output of passing tests
|
||||
* `--print-output-on-failure`: Automatically print the value of `$output` on
|
||||
failed tests
|
||||
* `--gather-test-outputs-in <directory>`: Gather the output of failing **and**
|
||||
passing tests as files in directory
|
||||
* Experimental: add return code checks to `run` via `!`/`-<N>` (#367, #507)
|
||||
* `install.sh` and `uninstall.sh` take an optional second parameter for the lib
|
||||
folder name to allow for multilib install, e.g. into lib64 (#452)
|
||||
* add `run` flag `--keep-empty-lines` to retain empty lines in `${lines[@]}` (#224,
|
||||
a894fbfa)
|
||||
* add `run` flag `--separate-stderr` which also fills `$stderr` and
|
||||
`$stderr_lines` (#47, 5c9b173d, #507)
|
||||
|
||||
### Fixed
|
||||
|
||||
* don't glob `run`'s `$output` when splitting into `${lines[@]}`
|
||||
(#151, #152, #158, #156, #281, #289)
|
||||
* remove empty line after test with pretty formatter on some terminals (#481)
|
||||
* don't run setup_file/teardown_file on files without tests, e.g. due to
|
||||
filtering (#484)
|
||||
* print final line without newline on Bash 3.2 for midtest (ERREXIT) failures
|
||||
too (#495, #145)
|
||||
* abort with error on missing flock/shlock when running in parallel mode (#496)
|
||||
* improved `set -u` test and fixed some unset variable accesses (#498, #501)
|
||||
* shorten suite/file/test temporary folder paths to leave enough space even on
|
||||
restricted systems (#503)
|
||||
|
||||
#### Documentation
|
||||
|
||||
* minor edits (#478)
|
||||
|
||||
## [1.4.1] - 2021-07-24
|
||||
|
||||
### Added
|
||||
|
||||
* Docker image architectures amd64, 386, arm64, arm/v7, arm/v6, ppc64le, s390x (#438)
|
||||
|
||||
### Fixed
|
||||
|
||||
* automatic push to Dockerhub (#438)
|
||||
|
||||
## [1.4.0] - 2021-07-23
|
||||
|
||||
### Added
|
||||
|
||||
* added BATS_TEST_TMPDIR, BATS_FILE_TMPDIR, BATS_SUITE_TMPDIR (#413)
|
||||
* added checks and improved documentation for `$BATS_TMPDIR` (#410)
|
||||
* the docker container now uses [tini](https://github.com/krallin/tini) as the
|
||||
container entrypoint to improve signal forwarding (#407)
|
||||
* script to uninstall bats from a given prefix (#400)
|
||||
* replace preprocessed file path (e.g. `/tmp/bats-run-22908-NP0f9h/bats.23102.src`)
|
||||
with original filename in stdout/err (but not FD3!) (#429)
|
||||
* print aborted command on SIGINT/CTRL+C (#368)
|
||||
* print error message when BATS_RUN_TMPDIR could not be created (#422)
|
||||
|
||||
#### Documentation
|
||||
|
||||
* added tutorial for new users (#397)
|
||||
* fixed example invocation of docker container (#440)
|
||||
* minor edits (#431, #439, #445, #463, #464, #465)
|
||||
|
||||
### Fixed
|
||||
|
||||
* fix `bats_tap_stream_unknown: command not found` with pretty formatter, when
|
||||
writing non compliant extended output (#412)
|
||||
* avoid collisions on `$BATS_RUN_TMPDIR` with `--no-tempdir-cleanup` and docker
|
||||
by using `mktemp` additionally to PID (#409)
|
||||
* pretty printer now puts text that is printed to FD 3 below the test name (#426)
|
||||
* `rm semaphores/slot-: No such file or directory` in parallel mode on MacOS
|
||||
(#434, #433)
|
||||
* fix YAML blocks in TAP13 formatter using `...` instead of `---` to start
|
||||
a block (#442)
|
||||
* fixed some typos in comments (#441, #447)
|
||||
* ensure `/code` exists in docker container, to make examples work again (#440)
|
||||
* also display error messages from free code (#429)
|
||||
* npm installed version on Windows: fix broken internal LIBEXEC paths (#459)
|
||||
|
||||
## [1.3.0] - 2021-03-08
|
||||
|
||||
### Added
|
||||
|
||||
* custom test-file extension via `BATS_FILE_EXTENSION` when searching for test
|
||||
files in a directory (#376)
|
||||
* TAP13 formatter, including millisecond timing (#337)
|
||||
* automatic release to NPM via GitHub Actions (#406)
|
||||
|
||||
#### Documentation
|
||||
|
||||
* added documentation about overusing `run` (#343)
|
||||
* improved documentation of `load` (#332)
|
||||
|
||||
### Changed
|
||||
|
||||
* recursive suite mode will follow symlinks now (#370)
|
||||
* split options for (file-) `--report-formatter` and (stdout) `--formatter` (#345)
|
||||
* **WARNING**: This changes the meaning of `--formatter junit`.
|
||||
stdout will now show unified xml instead of TAP. From now on, please use
|
||||
`--report-formatter junit` to obtain the `.xml` report file!
|
||||
* removed `--parallel-preserve-environment` flag, as this is the default
|
||||
behavior (#324)
|
||||
* moved CI from Travis/AppVeyor to GitHub Actions (#405)
|
||||
* preprocessed files are no longer removed if `--no-tempdir-cleanup` is
|
||||
specified (#395)
|
||||
|
||||
#### Documentation
|
||||
|
||||
* moved documentation to [readthedocs](https://bats-core.readthedocs.io/en/latest/)
|
||||
|
||||
### Fixed
|
||||
|
||||
#### Correctness
|
||||
|
||||
* fix internal failures due to unbound variables when test files use `set -u` (#392)
|
||||
* fix internal failures due to changes to `$PATH` in test files (#387)
|
||||
* fix test duration always being 0 on busybox installs (#363)
|
||||
* fix hangs on CTRL+C (#354)
|
||||
* make `BATS_TEST_NUMBER` count per file again (#326)
|
||||
* include `lib/` in npm package (#352)
|
||||
|
||||
#### Performance
|
||||
|
||||
* don't fork bomb in parallel mode (#339)
|
||||
* preprocess each file only once (#335)
|
||||
* avoid running duplicate files n^2 times (#338)
|
||||
|
||||
#### Documentation
|
||||
|
||||
* fix documentation for `--formatter junit` (#334)
|
||||
* fix documentation for `setup_file` variables (#333)
|
||||
* fix link to examples page (#331)
|
||||
* fix link to "File Descriptor 3" section (#301)
|
||||
|
||||
## [1.2.1] - 2020-07-06
|
||||
|
||||
### Added
|
||||
|
||||
* JUnit output and extensible formatter rewrite (#246)
|
||||
* `load` function now reads from absolute and relative paths, and $PATH (#282)
|
||||
* Beginner-friendly examples in /docs/examples (#243)
|
||||
* @peshay's `bats-file` fork contributed to `bats-core/bats-file` (#276)
|
||||
|
||||
### Changed
|
||||
|
||||
* Duplicate test names now error (previous behaviour was to issue a warning) (#286)
|
||||
* Changed default formatter in Docker to pretty by adding `ncurses` to
|
||||
Dockerfile, override with `--tap` (#239)
|
||||
* Replace "readlink -f" dependency with Bash solution (#217)
|
||||
|
||||
## [1.2.0] - 2020-04-25
|
||||
|
||||
Support parallel suite execution and filtering by test name.
|
||||
|
||||
### Added
|
||||
|
||||
* docs/CHANGELOG.md and docs/releasing.md (#122)
|
||||
* The `-f, --filter` flag to run only the tests matching a regular expression (#126)
|
||||
* Optimize stack trace capture (#138)
|
||||
* `--jobs n` flag to support parallel execution of tests with GNU parallel (#172)
|
||||
|
||||
### Changed
|
||||
|
||||
* AppVeyor builds are now semver-compliant (#123)
|
||||
* Add Bash 5 as test target (#181)
|
||||
* Always use upper case signal names to avoid locale dependent err… (#215)
|
||||
* Fix for tests reading from stdin (#227)
|
||||
* Fix wrong line numbers of errors in bash < 4.4 (#229)
|
||||
* Remove preprocessed source after test run (#232)
|
||||
|
||||
## [1.1.0] - 2018-07-08
|
||||
|
||||
This is the first release with new features relative to the original Bats 0.4.0.
|
||||
|
||||
### Added
|
||||
|
||||
* The `-r, --recursive` flag to scan directory arguments recursively for
|
||||
`*.bats` files (#109)
|
||||
* The `contrib/rpm/bats.spec` file to build RPMs (#111)
|
||||
|
||||
### Changed
|
||||
|
||||
* Travis exercises latest versions of Bash from 3.2 through 4.4 (#116, #117)
|
||||
* Error output highlights invalid command line options (#45, #46, #118)
|
||||
* Replaced `echo` with `printf` (#120)
|
||||
|
||||
### Fixed
|
||||
|
||||
* Fixed `BATS_ERROR_STATUS` getting lost when `bats_error_trap` fired multiple
|
||||
times under Bash 4.2.x (#110)
|
||||
* Updated `bin/bats` symlink resolution, handling the case on CentOS where
|
||||
`/bin` is a symlink to `/usr/bin` (#113, #115)
|
||||
|
||||
## [1.0.2] - 2018-06-18
|
||||
|
||||
* Fixed sstephenson/bats#240, whereby `skip` messages containing parentheses
|
||||
were truncated (#48)
|
||||
* Doc improvements:
|
||||
* Docker usage (#94)
|
||||
* Better README badges (#101)
|
||||
* Better installation instructions (#102, #104)
|
||||
* Packaging/installation improvements:
|
||||
* package.json update (#100)
|
||||
* Moved `libexec/` files to `libexec/bats-core/`, improved `install.sh` (#105)
|
||||
|
||||
## [1.0.1] - 2018-06-09
|
||||
|
||||
* Fixed a `BATS_CWD` bug introduced in #91 whereby it was set to the parent of
|
||||
`PWD`, when it should've been set to `PWD` itself (#98). This caused file
|
||||
names in stack traces to contain the basename of `PWD` as a prefix, when the
|
||||
names should've been purely relative to `PWD`.
|
||||
* Ensure the last line of test output prints when it doesn't end with a newline
|
||||
(#99). This was a quasi-bug introduced by replacing `sed` with `while` in #88.
|
||||
|
||||
## [1.0.0] - 2018-06-08
|
||||
|
||||
`1.0.0` generally preserves compatibility with `0.4.0`, but with some Bash
|
||||
compatibility improvements and a massive performance boost. In other words:
|
||||
|
||||
* all existing tests should remain compatible
|
||||
* tests that might've failed or exhibited unexpected behavior on earlier
|
||||
versions of Bash should now also pass or behave as expected
|
||||
|
||||
Changes:
|
||||
|
||||
* Added support for Docker.
|
||||
* Added support for test scripts that have the [unofficial strict
|
||||
mode](http://redsymbol.net/articles/unofficial-bash-strict-mode/) enabled.
|
||||
* Improved stability on Windows and macOS platforms.
|
||||
* Massive performance improvements, especially on Windows (#8)
|
||||
* Workarounds for inconsistent behavior between Bash versions (#82)
|
||||
* Workaround for preserving stack info after calling an exported function under
|
||||
Bash < 4.4 (#87)
|
||||
* Fixed TAP compliance for skipped tests
|
||||
* Added support for tabs in test names.
|
||||
* `bin/bats` and `install.sh` now work reliably on Windows (#91)
|
||||
|
||||
## [0.4.0] - 2014-08-13
|
||||
|
||||
* Improved the display of failing test cases. Bats now shows the source code of
|
||||
failing test lines, along with full stack traces including function names,
|
||||
filenames, and line numbers.
|
||||
* Improved the display of the pretty-printed test summary line to include the
|
||||
number of skipped tests, if any.
|
||||
* Improved the speed of the preprocessor, dramatically shortening test and suite
|
||||
startup times.
|
||||
* Added support for absolute pathnames to the `load` helper.
|
||||
* Added support for single-line `@test` definitions.
|
||||
* Added bats(1) and bats(7) manual pages.
|
||||
* Modified the `bats` command to default to TAP output when the `$CI` variable
|
||||
is set, to better support environments such as Travis CI.
|
||||
|
||||
## [0.3.1] - 2013-10-28
|
||||
|
||||
* Fixed an incompatibility with the pretty formatter in certain environments
|
||||
such as tmux.
|
||||
* Fixed a bug where the pretty formatter would crash if the first line of a test
|
||||
file's output was invalid TAP.
|
||||
|
||||
## [0.3.0] - 2013-10-21
|
||||
|
||||
* Improved formatting for tests run from a terminal. Failing tests are now
|
||||
colored in red, and the total number of failing tests is displayed at the end
|
||||
of the test run. When Bats is not connected to a terminal (e.g. in CI runs),
|
||||
or when invoked with the `--tap` flag, output is displayed in standard TAP
|
||||
format.
|
||||
* Added the ability to skip tests using the `skip` command.
|
||||
* Added a message to failing test case output indicating the file and line
|
||||
number of the statement that caused the test to fail.
|
||||
* Added "ad-hoc" test suite support. You can now invoke `bats` with multiple
|
||||
filename or directory arguments to run all the specified tests in aggregate.
|
||||
* Added support for test files with Windows line endings.
|
||||
* Fixed regular expression warnings from certain versions of Bash.
|
||||
* Fixed a bug running tests containing lines that begin with `-e`.
|
||||
|
||||
## [0.2.0] - 2012-11-16
|
||||
|
||||
* Added test suite support. The `bats` command accepts a directory name
|
||||
containing multiple test files to be run in aggregate.
|
||||
* Added the ability to count the number of test cases in a file or suite by
|
||||
passing the `-c` flag to `bats`.
|
||||
* Preprocessed sources are cached between test case runs in the same file for
|
||||
better performance.
|
||||
|
||||
## [0.1.0] - 2011-12-30
|
||||
|
||||
* Initial public release.
|
||||
|
||||
[Unreleased]: https://github.com/bats-core/bats-core/compare/v1.7.0...HEAD
|
||||
[1.7.0]: https://github.com/bats-core/bats-core/compare/v1.6.1...v1.7.0
|
||||
[1.6.1]: https://github.com/bats-core/bats-core/compare/v1.6.0...v1.6.1
|
||||
[1.6.0]: https://github.com/bats-core/bats-core/compare/v1.5.0...v1.6.0
|
||||
[1.5.0]: https://github.com/bats-core/bats-core/compare/v1.4.1...v1.5.0
|
||||
[1.4.1]: https://github.com/bats-core/bats-core/compare/v1.4.0...v1.4.1
|
||||
[1.4.0]: https://github.com/bats-core/bats-core/compare/v1.3.0...v1.4.0
|
||||
[1.3.0]: https://github.com/bats-core/bats-core/compare/v1.2.1...v1.3.0
|
||||
[1.2.1]: https://github.com/bats-core/bats-core/compare/v1.2.0...v1.2.1
|
||||
[1.2.0]: https://github.com/bats-core/bats-core/compare/v1.1.0...v1.2.0
|
||||
[1.1.0]: https://github.com/bats-core/bats-core/compare/v1.0.2...v1.1.0
|
||||
[1.0.2]: https://github.com/bats-core/bats-core/compare/v1.0.1...v1.0.2
|
||||
[1.0.1]: https://github.com/bats-core/bats-core/compare/v1.0.0...v1.0.1
|
||||
[1.0.0]: https://github.com/bats-core/bats-core/compare/v0.4.0...v1.0.0
|
||||
[0.4.0]: https://github.com/bats-core/bats-core/compare/v0.3.1...v0.4.0
|
||||
[0.3.1]: https://github.com/bats-core/bats-core/compare/v0.3.0...v0.3.1
|
||||
[0.3.0]: https://github.com/bats-core/bats-core/compare/v0.2.0...v0.3.0
|
||||
[0.2.0]: https://github.com/bats-core/bats-core/compare/v0.1.0...v0.2.0
|
||||
[0.1.0]: https://github.com/bats-core/bats-core/commits/v0.1.0
|
||||
|
||||
@@ -0,0 +1,4 @@
|
||||
# This enables automatic code review requests per:
|
||||
# - https://help.github.com/articles/about-codeowners/
|
||||
# - https://help.github.com/articles/enabling-required-reviews-for-pull-requests/
|
||||
* @bats-core/bats-core
|
||||
@@ -0,0 +1,92 @@
|
||||
# Contributor Covenant Code of Conduct
|
||||
|
||||
## Our Pledge
|
||||
|
||||
In the interest of fostering an open and welcoming environment, we as
|
||||
contributors and maintainers pledge to making participation in our project and
|
||||
our community a harassment-free experience for everyone, regardless of age, body
|
||||
size, disability, ethnicity, gender identity and expression, level of experience,
|
||||
nationality, personal appearance, race, religion, or sexual identity and
|
||||
orientation.
|
||||
|
||||
## Our Standards
|
||||
|
||||
Examples of behavior that contributes to creating a positive environment
|
||||
include:
|
||||
|
||||
* Using welcoming and inclusive language
|
||||
* Being respectful of differing viewpoints and experiences
|
||||
* Gracefully accepting constructive criticism
|
||||
* Focusing on what is best for the community
|
||||
* Showing empathy towards other community members
|
||||
|
||||
Examples of unacceptable behavior by participants include:
|
||||
|
||||
* The use of sexualized language or imagery and unwelcome sexual attention or
|
||||
advances
|
||||
* Trolling, insulting/derogatory comments, and personal or political attacks
|
||||
* Public or private harassment
|
||||
* Publishing others' private information, such as a physical or electronic
|
||||
address, without explicit permission
|
||||
* Other conduct which could reasonably be considered inappropriate in a
|
||||
professional setting
|
||||
|
||||
## Our Responsibilities
|
||||
|
||||
Project maintainers are responsible for clarifying the standards of acceptable
|
||||
behavior and are expected to take appropriate and fair corrective action in
|
||||
response to any instances of unacceptable behavior.
|
||||
|
||||
Project maintainers have the right and responsibility to remove, edit, or
|
||||
reject comments, commits, code, wiki edits, issues, and other contributions
|
||||
that are not aligned to this Code of Conduct, or to ban temporarily or
|
||||
permanently any contributor for other behaviors that they deem inappropriate,
|
||||
threatening, offensive, or harmful.
|
||||
|
||||
## Scope
|
||||
|
||||
This Code of Conduct applies both within project spaces and in public spaces
|
||||
when an individual is representing the project or its community. Examples of
|
||||
representing a project or community include using an official project e-mail
|
||||
address, posting via an official social media account, or acting as an appointed
|
||||
representative at an online or offline event. Representation of a project may be
|
||||
further defined and clarified by project maintainers.
|
||||
|
||||
## Enforcement
|
||||
|
||||
Instances of abusive, harassing, or otherwise unacceptable behavior may be
|
||||
reported by contacting one of the current [project maintainers](#project-maintainers) listed below. All
|
||||
complaints will be reviewed and investigated and will result in a response that
|
||||
is deemed necessary and appropriate to the circumstances. The project team is
|
||||
obligated to maintain confidentiality with regard to the reporter of an incident.
|
||||
Further details of specific enforcement policies may be posted separately.
|
||||
|
||||
Project maintainers who do not follow or enforce the Code of Conduct in good
|
||||
faith may face temporary or permanent repercussions as determined by other
|
||||
members of the project's leadership.
|
||||
|
||||
## Project Maintainers
|
||||
|
||||
### Current Maintainers
|
||||
|
||||
* [Bianca Tamayo][bt-gh]
|
||||
* [Mike Bland][mb-gh]
|
||||
* [Jason Karns][jk-gh]
|
||||
* [Andrew Martin][am-gh]
|
||||
|
||||
### Past Maintainers
|
||||
|
||||
* Sam Stephenson <<sstephenson@gmail.com>> (Original author)
|
||||
|
||||
## Attribution
|
||||
|
||||
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
|
||||
available at [http://contributor-covenant.org/version/1/4][version]
|
||||
|
||||
[bt-gh]: https://github.com/btamayo
|
||||
[mb-gh]: https://github.com/mbland
|
||||
[jk-gh]: https://github.com/jasonkarns
|
||||
[am-gh]: https://github.com/sublimino
|
||||
|
||||
[homepage]: https://contributor-covenant.org
|
||||
[version]: https://contributor-covenant.org/version/1/4/
|
||||
@@ -0,0 +1,232 @@
|
||||
# Contributing Guidelines
|
||||
|
||||
## Welcome!
|
||||
|
||||
Thank you for considering contributing to this project's
|
||||
development and/or documentation. Just a reminder: if you're new to this project
|
||||
or to OSS and want to find issues to work on, please check the following labels
|
||||
on issues:
|
||||
|
||||
- [help wanted][helpwantedlabel]
|
||||
- [docs][docslabel]
|
||||
- [good first issue][goodfirstissuelabel]
|
||||
|
||||
[docslabel]: https://github.com/bats-core/bats-core/labels/docs
|
||||
[helpwantedlabel]: https://github.com/bats-core/bats-core/labels/help%20wanted
|
||||
[goodfirstissuelabel]: https://github.com/bats-core/bats-core/labels/good%20first%20issue
|
||||
|
||||
To see all labels and their meanings, [check this wiki page][labelswiki].
|
||||
|
||||
[labelswiki]: https://github.com/bats-core/bats-core/wiki/GitHub-Issue-Labels
|
||||
|
||||
## Table of contents
|
||||
|
||||
* [Contributing Guidelines](#contributing-guidelines)
|
||||
* [Welcome!](#welcome)
|
||||
* [Table of contents](#table-of-contents)
|
||||
* [Quick links](#quick-links)
|
||||
* [Code of conduct](#code-of-conduct)
|
||||
* [Asking questions](#asking-questions)
|
||||
* [Updating documentation](#updating-documentation)
|
||||
* [Testing](#testing)
|
||||
* [Coding conventions](#coding-conventions)
|
||||
* [Function declarations](#function-declarations)
|
||||
* [Variable and parameter declarations](#variable-and-parameter-declarations)
|
||||
* [Command substitution](#command-substitution)
|
||||
* [Process substitution](#process-substitution)
|
||||
* [Conditionals and loops](#conditionals-and-loops)
|
||||
* [Generating output](#generating-output)
|
||||
* [Signal names](#signal-names)
|
||||
* [Gotchas](#gotchas)
|
||||
* [Open Source License](#open-source-license)
|
||||
* [Credits](#credits)
|
||||
|
||||
## Quick links
|
||||
|
||||
- [Gitter channel →][gitterurl]: Feel free to come chat with us on Gitter
|
||||
- [README →][README]
|
||||
- [Code of conduct →][CODE_OF_CONDUCT]
|
||||
- [License information →][LICENSE]
|
||||
- [Original repository →][repohome]
|
||||
- [Issues →][repoissues]
|
||||
- [Pull requests →][repoprs]
|
||||
- [Milestones →][repomilestones]
|
||||
- [Projects →][repoprojects]
|
||||
|
||||
[README]: https://github.com/bats-core/bats-core/blob/master/README.md
|
||||
[CODE_OF_CONDUCT]: https://github.com/bats-core/bats-core/blob/master/docs/CODE_OF_CONDUCT.md
|
||||
[LICENSE]: https://github.com/bats-core/bats-core/blob/master/LICENSE.md
|
||||
|
||||
## Code of conduct
|
||||
|
||||
Harassment or rudeness of any kind will not be tolerated, period. For
|
||||
specifics, see the [CODE_OF_CONDUCT][] file.
|
||||
|
||||
## Asking questions
|
||||
|
||||
Please check the [documentation][documentation] or existing [discussions][] and [issues][repoissues] first.
|
||||
|
||||
If you cannot find an answer to your question, please feel free to hop on our
|
||||
[Gitter][gitterurl]. [](https://gitter.im/bats-core/bats-core)
|
||||
|
||||
## Updating documentation
|
||||
|
||||
We love documentation and people who love documentation!
|
||||
|
||||
If you love writing clear, accessible docs, please don't be shy about pull
|
||||
requests. Remember: docs are just as important as code.
|
||||
|
||||
Also: _no typo is too small to fix!_ Really. Of course, batches of fixes are
|
||||
preferred, but even one nit is one nit too many.
|
||||
|
||||
## Testing
|
||||
|
||||
- Continuous integration status: [](https://github.com/bats-core/bats-core/actions?query=workflow%3ATests)
|
||||
|
||||
To run all tests:
|
||||
```sh
|
||||
bin/bats test
|
||||
```
|
||||
|
||||
To run a single test file:
|
||||
```sh
|
||||
bin/bats test/file.bats
|
||||
```
|
||||
|
||||
When running from a terminal, Bats uses the *pretty* formatter by default.
|
||||
However, to debug Bats you might need to see the raw test output.
|
||||
The **cat** formatter is intended as an internal debugging tool because
|
||||
it does not process test outputs.
|
||||
To use it, run Bats with the `--formatter cat` option.
|
||||
|
||||
## Coding conventions
|
||||
|
||||
Use (`shfmt`)[https://github.com/mvdan/sh#shfmt] and [ShellCheck](https://www.shellcheck.net/). The CI will enforce this.
|
||||
|
||||
Use `snake_case` for all identifiers.
|
||||
|
||||
### Function declarations
|
||||
|
||||
- Declare functions without the `function` keyword.
|
||||
- Strive to always use `return`, never `exit`, unless an error condition is
|
||||
severe enough to warrant it.
|
||||
- Calling `exit` makes it difficult for the caller to recover from an error,
|
||||
or to compose new commands from existing ones.
|
||||
|
||||
### Variable and parameter declarations
|
||||
|
||||
- Declare all variables inside functions using `local`.
|
||||
- Declare temporary file-level variables using `declare`. Use `unset` to remove
|
||||
them when finished.
|
||||
- Don't use `local -r`, as a readonly local variable in one scope can cause a
|
||||
conflict when it calls a function that declares a `local` variable of the same
|
||||
name.
|
||||
- Don't use type flags with `declare` or `local`. Assignments to integer
|
||||
variables in particular may behave differently, and it has no effect on array
|
||||
variables.
|
||||
- For most functions, the first lines should use `local` declarations to
|
||||
assign the original positional parameters to more meaningful names, e.g.:
|
||||
```bash
|
||||
format_summary() {
|
||||
local cmd_name="$1"
|
||||
local summary="$2"
|
||||
local longest_name_len="$3"
|
||||
```
|
||||
For very short functions, this _may not_ be necessary, e.g.:
|
||||
```bash
|
||||
has_spaces() {
|
||||
[[ "$1" != "${1//[[:space:]]/}" ]]
|
||||
}
|
||||
```
|
||||
|
||||
### Command substitution
|
||||
|
||||
- If possible, don't. While this capability is one of Bash's core strengths,
|
||||
every new process created by Bats makes the framework slower, and speed is
|
||||
critical to encouraging the practice of automated testing. (This is especially
|
||||
true on Windows, [where process creation is one or two orders of magnitude
|
||||
slower][win-slow]. See [bats-core/bats-core#8][pr-8] for an illustration of
|
||||
the difference avoiding subshells makes.) Bash is quite powerful; see if you
|
||||
can do what you need in pure Bash first.
|
||||
- If you need to capture the output from a function, store the output using
|
||||
`printf -v` instead if possible. `-v` specifies the name of the variable into
|
||||
which to write the result; the caller can supply this name as a parameter.
|
||||
- If you must use command substitution, use `$()` instead of backticks, as it's
|
||||
more robust, more searchable, and can be nested.
|
||||
|
||||
[win-slow]: https://rufflewind.com/2014-08-23/windows-bash-slow
|
||||
[pr-8]: https://github.com/bats-core/bats-core/pull/8
|
||||
|
||||
### Process substitution
|
||||
|
||||
- If possible, don't use it. See the advice on avoiding subprocesses and using
|
||||
`printf -v` in the **Command substitution** section above.
|
||||
- Use wherever necessary and possible, such as when piping input into a `while`
|
||||
loop (which avoids having the loop body execute in a subshell) or running a
|
||||
command taking multiple filename arguments based on output from a function or
|
||||
pipeline (e.g. `diff`).
|
||||
- *Warning*: It is impossible to directly determine the exit status of a process
|
||||
substitution; emitting an exit status as the last line of output is a possible
|
||||
workaround.
|
||||
|
||||
### Conditionals and loops
|
||||
|
||||
- Always use `[[` and `]]` for evaluating variables. Per the guideline under
|
||||
**Formatting**, quote variables and strings within the brackets, but not
|
||||
regular expressions (or variables containing regular expressions) appearing
|
||||
on the right side of the `=~` operator.
|
||||
|
||||
### Generating output
|
||||
|
||||
- Use `printf` instead of `echo`. Both are Bash builtins, and there's no
|
||||
perceptible performance difference when running Bats under the `time` builtin.
|
||||
However, `printf` provides a more consistent experience in general, as `echo`
|
||||
has limitations to the arguments it accepts, and even the same version of Bash
|
||||
may produce different results for `echo` based on how the binary was compiled.
|
||||
See [Stack Overflow: Why is printf better than echo?][printf-vs-echo] for
|
||||
excruciating details.
|
||||
|
||||
[printf-vs-echo]: https://unix.stackexchange.com/a/65819
|
||||
|
||||
### Signal names
|
||||
|
||||
Always use upper case signal names (e.g. `trap - INT EXIT`) to avoid locale
|
||||
dependent errors. In some locales (for example Turkish, see
|
||||
[Turkish dotless i](https://en.wikipedia.org/wiki/Dotted_and_dotless_I)) lower
|
||||
case signal names cause Bash to error. An example of the problem:
|
||||
|
||||
```bash
|
||||
$ echo "tr_TR.UTF-8 UTF-8" >> /etc/locale.gen && locale-gen tr_TR.UTF-8 # Ubuntu derivatives
|
||||
$ LC_CTYPE=tr_TR.UTF-8 LC_MESSAGES=C bash -c 'trap - int && echo success'
|
||||
bash: line 0: trap: int: invalid signal specification
|
||||
$ LC_CTYPE=tr_TR.UTF-8 LC_MESSAGES=C bash -c 'trap - INT && echo success'
|
||||
success
|
||||
```
|
||||
|
||||
|
||||
## Credits
|
||||
|
||||
The [official bash logo](https://github.com/odb/official-bash-logo) is copyrighted
|
||||
by the [Free Software Foundation](https://www.fsf.org/), 2016 under the [Free Art License](http://artlibre.org/licence/lal/en/)
|
||||
|
||||
This guide borrows **heavily** from [@mbland's go-script-bash][gsb] (with some
|
||||
sections directly quoted), which in turn was
|
||||
drafted with tips from [Wrangling Web Contributions: How to Build
|
||||
a CONTRIBUTING.md][moz] and with some inspiration from [the Atom project's
|
||||
CONTRIBUTING.md file][atom].
|
||||
|
||||
[gsb]: https://github.com/mbland/go-script-bash/blob/master/CONTRIBUTING.md
|
||||
[moz]: https://mozillascience.github.io/working-open-workshop/contributing/
|
||||
[atom]: https://github.com/atom/atom/blob/master/CONTRIBUTING.md
|
||||
|
||||
[discussions]: https://github.com/bats-core/bats-core/discussions
|
||||
[documentation]: https://bats-core.readthedocs.io/
|
||||
[repoprojects]: https://github.com/bats-core/bats-core/projects
|
||||
[repomilestones]: https://github.com/bats-core/bats-core/milestones
|
||||
[repoprs]: https://github.com/bats-core/bats-core/pulls
|
||||
[repoissues]: https://github.com/bats-core/bats-core/issues
|
||||
[repohome]: https://github.com/bats-core/bats-core
|
||||
|
||||
[osmit]: https://opensource.org/licenses/MIT
|
||||
|
||||
[gitterurl]: https://gitter.im/bats-core/bats-core
|
||||
@@ -0,0 +1,20 @@
|
||||
# Minimal makefile for Sphinx documentation
|
||||
#
|
||||
|
||||
# You can set these variables from the command line, and also
|
||||
# from the environment for the first two.
|
||||
SPHINXOPTS ?=
|
||||
SPHINXBUILD ?= sphinx-build
|
||||
SOURCEDIR = source
|
||||
BUILDDIR = build
|
||||
|
||||
# Put it first so that "make" without argument is like "make help".
|
||||
help:
|
||||
@$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
|
||||
|
||||
.PHONY: help Makefile
|
||||
|
||||
# Catch-all target: route all unknown targets to Sphinx using the new
|
||||
# "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS).
|
||||
%: Makefile
|
||||
@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
|
||||
@@ -0,0 +1,5 @@
|
||||
- [ ] I have reviewed the [Contributor Guidelines][contributor].
|
||||
- [ ] I have reviewed the [Code of Conduct][coc] and agree to abide by it
|
||||
|
||||
[contributor]: https://github.com/bats-core/bats-core/blob/master/docs/CONTRIBUTING.md
|
||||
[coc]: https://github.com/bats-core/bats-core/blob/master/docs/CODE_OF_CONDUCT.md
|
||||
@@ -0,0 +1,6 @@
|
||||
# Examples
|
||||
|
||||
This directory contains example .bats files.
|
||||
See the [bats-core wiki][examples] for more details.
|
||||
|
||||
[examples]: https://github.com/bats-core/bats-core/wiki/Examples
|
||||
@@ -0,0 +1,16 @@
|
||||
#!/usr/bin/env bash
|
||||
|
||||
# "unofficial" bash strict mode
|
||||
# See: http://redsymbol.net/articles/unofficial-bash-strict-mode
|
||||
set -o errexit # Exit when simple command fails 'set -e'
|
||||
set -o errtrace # Exit on error inside any functions or subshells.
|
||||
set -o nounset # Trigger error when expanding unset variables 'set -u'
|
||||
set -o pipefail # Do not hide errors within pipes 'set -o pipefail'
|
||||
set -o xtrace # Display expanded command and arguments 'set -x'
|
||||
IFS=$'\n\t' # Split words on \n\t rather than spaces
|
||||
|
||||
main() {
|
||||
tar -czf "$dst_tarball" -C "$src_dir" .
|
||||
}
|
||||
|
||||
main "$@"
|
||||
+51
@@ -0,0 +1,51 @@
|
||||
#!/usr/bin/env bats
|
||||
|
||||
setup() {
|
||||
export dst_tarball="${BATS_TMPDIR}/dst.tar.gz"
|
||||
export src_dir="${BATS_TMPDIR}/src_dir"
|
||||
|
||||
rm -rf "${dst_tarball}" "${src_dir}"
|
||||
mkdir "${src_dir}"
|
||||
touch "${src_dir}"/{a,b,c}
|
||||
}
|
||||
|
||||
main() {
|
||||
bash "${BATS_TEST_DIRNAME}"/package-tarball
|
||||
}
|
||||
|
||||
@test "fail when \$src_dir and \$dst_tarball are unbound" {
|
||||
unset src_dir dst_tarball
|
||||
|
||||
run main
|
||||
[ "${status}" -ne 0 ]
|
||||
}
|
||||
|
||||
@test "fail when \$src_dir is a non-existent directory" {
|
||||
# shellcheck disable=SC2030
|
||||
src_dir='not-a-dir'
|
||||
|
||||
run main
|
||||
[ "${status}" -ne 0 ]
|
||||
}
|
||||
|
||||
# shellcheck disable=SC2016
|
||||
@test "pass when \$src_dir directory is empty" {
|
||||
# shellcheck disable=SC2031,SC2030
|
||||
rm -rf "${src_dir:?}/*"
|
||||
|
||||
run main
|
||||
echo "$output"
|
||||
[ "${status}" -eq 0 ]
|
||||
}
|
||||
|
||||
# shellcheck disable=SC2016
|
||||
@test "files in \$src_dir are added to tar archive" {
|
||||
run main
|
||||
[ "${status}" -eq 0 ]
|
||||
|
||||
run tar tf "$dst_tarball"
|
||||
[ "${status}" -eq 0 ]
|
||||
[[ "${output}" =~ a ]]
|
||||
[[ "${output}" =~ b ]]
|
||||
[[ "${output}" =~ c ]]
|
||||
}
|
||||
@@ -0,0 +1,4 @@
|
||||
import pickle
|
||||
with open("build/doctrees/environment.pickle", "rb") as f:
|
||||
dat = pickle.load(f)
|
||||
print(dat.domaindata['std']['labels'])
|
||||
@@ -0,0 +1,35 @@
|
||||
@ECHO OFF
|
||||
|
||||
pushd %~dp0
|
||||
|
||||
REM Command file for Sphinx documentation
|
||||
|
||||
if "%SPHINXBUILD%" == "" (
|
||||
set SPHINXBUILD=sphinx-build
|
||||
)
|
||||
set SOURCEDIR=source
|
||||
set BUILDDIR=build
|
||||
|
||||
if "%1" == "" goto help
|
||||
|
||||
%SPHINXBUILD% >NUL 2>NUL
|
||||
if errorlevel 9009 (
|
||||
echo.
|
||||
echo.The 'sphinx-build' command was not found. Make sure you have Sphinx
|
||||
echo.installed, then set the SPHINXBUILD environment variable to point
|
||||
echo.to the full path of the 'sphinx-build' executable. Alternatively you
|
||||
echo.may add the Sphinx directory to PATH.
|
||||
echo.
|
||||
echo.If you don't have Sphinx installed, grab it from
|
||||
echo.http://sphinx-doc.org/
|
||||
exit /b 1
|
||||
)
|
||||
|
||||
%SPHINXBUILD% -M %1 %SOURCEDIR% %BUILDDIR% %SPHINXOPTS% %O%
|
||||
goto end
|
||||
|
||||
:help
|
||||
%SPHINXBUILD% -M help %SOURCEDIR% %BUILDDIR% %SPHINXOPTS% %O%
|
||||
|
||||
:end
|
||||
popd
|
||||
@@ -0,0 +1,127 @@
|
||||
# Releasing a new Bats version
|
||||
|
||||
These notes reflect the current process. There's a lot more we could do, in
|
||||
terms of automation and expanding the number of platforms to which we formally
|
||||
release (see #103).
|
||||
|
||||
## Update docs/CHANGELOG.md
|
||||
|
||||
Create a new entry at the top of `docs/CHANGELOG.md` that enumerates the
|
||||
significant updates to the new version.
|
||||
|
||||
## Bumping the version number
|
||||
|
||||
Bump the version numbers in the following files:
|
||||
|
||||
- contrib/rpm/bats.spec
|
||||
- libexec/bats-core/bats
|
||||
- package.json
|
||||
|
||||
Commit these changes (including the `docs/CHANGELOG.md` changes) in a commit
|
||||
with the message `Bats <VERSION>`, where `<VERSION>` is the new version number.
|
||||
|
||||
Create a new signed, annotated tag with:
|
||||
|
||||
```bash
|
||||
$ git tag -a -s <VERSION>
|
||||
```
|
||||
|
||||
Include the `docs/CHANGELOG.md` notes corresponding to the new version as the
|
||||
tag annotation, except the first line should be: `Bats <VERSION> - YYYY-MM-DD`
|
||||
and any Markdown headings should become plain text, e.g.:
|
||||
|
||||
```md
|
||||
### Added
|
||||
```
|
||||
|
||||
should become:
|
||||
|
||||
```md
|
||||
Added:
|
||||
```
|
||||
|
||||
## Create a GitHub release
|
||||
|
||||
Push the new version commit and tag to GitHub via the following:
|
||||
|
||||
```bash
|
||||
$ git push --follow-tags
|
||||
```
|
||||
|
||||
Then visit https://github.com/bats-core/bats-core/releases, and:
|
||||
|
||||
* Click **Draft a new release**.
|
||||
* Select the new version tag.
|
||||
* Name the release: `Bats <VERSION>`.
|
||||
* Paste the same notes from the version tag annotation as the description,
|
||||
except change the first line to read: `Released: YYYY-MM-DD`.
|
||||
* Click **Publish release**.
|
||||
|
||||
For more on `git push --follow-tags`, see:
|
||||
|
||||
* [git push --follow-tags in the online manual][ft-man]
|
||||
* [Stack Overflow: How to push a tag to a remote repository using Git?][ft-so]
|
||||
|
||||
[ft-man]: https://git-scm.com/docs/git-push#git-push---follow-tags
|
||||
[ft-so]: https://stackoverflow.com/a/26438076
|
||||
|
||||
## NPM
|
||||
|
||||
`npm publish`. Pretty easy!
|
||||
|
||||
For the paranoid, use `npm pack` and install the resulting tarball locally with
|
||||
`npm install` before publishing.
|
||||
|
||||
## Homebrew
|
||||
|
||||
The basic instructions are in the [Submit a new version of an existing
|
||||
formula][brew] section of the Homebrew docs.
|
||||
|
||||
[brew]: https://github.com/Homebrew/brew/blob/master/docs/How-To-Open-a-Homebrew-Pull-Request.md#submit-a-new-version-of-an-existing-formula
|
||||
|
||||
An example using v1.1.0 (notice that this uses the sha256 sum of the tarball):
|
||||
|
||||
```bash
|
||||
$ curl -LOv https://github.com/bats-core/bats-core/archive/v1.1.0.tar.gz
|
||||
$ openssl sha256 v1.1.0.tar.gz
|
||||
SHA256(v1.1.0.tar.gz)=855d8b8bed466bc505e61123d12885500ef6fcdb317ace1b668087364717ea82
|
||||
|
||||
# Add the --dry-run flag to see the individual steps without executing.
|
||||
$ brew bump-formula-pr \
|
||||
--url=https://github.com/bats-core/bats-core/archive/v1.1.0.tar.gz \
|
||||
--sha256=855d8b8bed466bc505e61123d12885500ef6fcdb317ace1b668087364717ea82
|
||||
```
|
||||
This resulted in https://github.com/Homebrew/homebrew-core/pull/29864, which was
|
||||
automatically merged once the build passed.
|
||||
|
||||
## Alpine Linux
|
||||
|
||||
An example using v1.1.0 (notice that this uses the sha512 sum of the Zip file):
|
||||
|
||||
```bash
|
||||
$ curl -LOv https://github.com/bats-core/bats-core/archive/v1.1.0.zip
|
||||
$ openssl sha512 v1.1.0.zip
|
||||
SHA512(v1.1.0.zip)=accd83cfec0025a2be40982b3f9a314c2bbf72f5c85daffa9e9419611904a8d34e376919a5d53e378382e0f3794d2bd781046d810225e2a77812474e427bed9e
|
||||
```
|
||||
|
||||
After cloning alpinelinux/aports, I used the above information to create:
|
||||
https://github.com/alpinelinux/aports/pull/4696
|
||||
|
||||
**Note:** Currently users must enable the `edge` branch of the `community` repo
|
||||
by adding/uncommenting the corresponding entry in `/etc/apk/repositories`.
|
||||
|
||||
## Announce
|
||||
|
||||
It's worth making a brief announcement like [the v1.1.0 announcement via
|
||||
Gitter][gitter]:
|
||||
|
||||
[gitter]: https://gitter.im/bats-core/bats-core?at=5b42c9a57b811a6d63daacb5
|
||||
|
||||
```
|
||||
v1.1.0 is now available via Homebrew and npm:
|
||||
https://github.com/bats-core/bats-core/releases/tag/v1.1.0
|
||||
|
||||
It'll eventually be available in Alpine via the edge branch of the community
|
||||
repo once alpinelinux/aports#4696 gets merged. (Check /etc/apk/repositories to
|
||||
ensure this repo is enabled.)
|
||||
```
|
||||
@@ -0,0 +1,24 @@
|
||||
# Our Logo
|
||||
|
||||
<div align="center">
|
||||
<picture>
|
||||
<source media="(prefers-color-scheme: dark)" srcset="dark_mode_cube.svg">
|
||||
<img alt="" src="light_mode_cube.svg">
|
||||
</picture>
|
||||
</div>
|
||||
|
||||
## Usage Guide for Third Parties
|
||||
|
||||
There may be cases where you want to use our logo. Please follow these rules:
|
||||
|
||||
**DO** use our logo as a part of thumbnails, banners/images in articles, or on a README in reference to the this project.
|
||||
|
||||
**DO** use our logo to relate resources back to the Bats project, like file associations or links to the project page.
|
||||
|
||||
**DO NOT** use our logo as the face of a third-party tool or extension that is not affiliated with the Bats project or Bats maintainers.
|
||||
|
||||
If in doubt, ask if your intended usecase is approved.
|
||||
|
||||
## Credits
|
||||
|
||||
The Bats Logo was created by [Vukory](https://www.artstation.com/vukory) ([Github](https://github.com/vukory)) and sponsored by [SethFalco](https://github.com/SethFalco).
|
||||
@@ -0,0 +1,55 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!-- Created with Inkscape (http://www.inkscape.org/) -->
|
||||
|
||||
<svg
|
||||
width="54.261147mm"
|
||||
height="43.081844mm"
|
||||
viewBox="0 0 54.261147 43.081844"
|
||||
version="1.1"
|
||||
id="svg2478"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:svg="http://www.w3.org/2000/svg">
|
||||
<defs
|
||||
id="defs2475" />
|
||||
<g
|
||||
id="layer1"
|
||||
transform="translate(-71.195776,-139.44713)">
|
||||
<g
|
||||
id="g9615">
|
||||
<g
|
||||
id="g41739"
|
||||
transform="matrix(0.85714226,0,0,0.85714226,-1218.3151,927.76689)"
|
||||
style="display:inline;stroke-width:1.16667">
|
||||
<g
|
||||
id="g24595"
|
||||
transform="matrix(1.8087061,0,0,1.8087061,-1236.9066,713.01919)"
|
||||
style="stroke-width:0.64503">
|
||||
<path
|
||||
style="fill:#b1bbc0;fill-opacity:1;stroke:none;stroke-width:0.51199;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
d="m 1533.1344,-889.4993 2.9413,-2.92919 0.8498,3.37817 13.7088,-13.65367 -1.5371,6.21648 1.1421,4.5359 -3.0032,2.99127 -1.666,6.73802 -8.7932,3.67943 -3.6425,3.62793 -3.6425,-3.62793 -8.7932,-3.67943 -1.666,-6.73802 -3.0033,-2.99127 1.1421,-4.5359 -1.537,-6.21648 13.7088,13.65367 0.8498,-3.37817 z"
|
||||
id="path41727" />
|
||||
<g
|
||||
id="g41737"
|
||||
style="fill:#ffffff;fill-opacity:1;stroke-width:0.64503">
|
||||
<path
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:0.170933;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
d="m 1545.57,-882.22245 -8.7932,3.67942 4.7021,-4.68334 z"
|
||||
id="path41729" />
|
||||
<path
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:0.170933;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
d="m 1533.1343,-885.27404 17.5,-17.42995 -3.3983,13.74351 -5.7571,5.73411 z"
|
||||
id="path41731" />
|
||||
<path
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:0.170933;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
d="m 1520.6986,-882.22245 8.7932,3.67942 -4.7021,-4.68334 z"
|
||||
id="path41733" />
|
||||
<path
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:0.170933;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
d="m 1533.1343,-885.27404 -17.5,-17.42995 3.3983,13.74351 5.7571,5.73411 z"
|
||||
id="path41735" />
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 2.7 KiB |
@@ -0,0 +1,98 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!-- Created with Inkscape (http://www.inkscape.org/) -->
|
||||
|
||||
<svg
|
||||
width="54mm"
|
||||
height="49.773262mm"
|
||||
viewBox="0 0 54 49.773262"
|
||||
version="1.1"
|
||||
id="svg2478"
|
||||
sodipodi:docname="dark_mode_cube.svg"
|
||||
inkscape:version="1.1.2 (b8e25be833, 2022-02-05)"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:svg="http://www.w3.org/2000/svg">
|
||||
<sodipodi:namedview
|
||||
id="namedview22"
|
||||
pagecolor="#ffffff"
|
||||
bordercolor="#666666"
|
||||
borderopacity="1.0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:pageopacity="0.0"
|
||||
inkscape:pagecheckerboard="true"
|
||||
inkscape:document-units="mm"
|
||||
showgrid="false"
|
||||
inkscape:zoom="1.5617892"
|
||||
inkscape:cx="16.007282"
|
||||
inkscape:cy="85.158741"
|
||||
inkscape:window-width="1920"
|
||||
inkscape:window-height="1017"
|
||||
inkscape:window-x="-8"
|
||||
inkscape:window-y="-8"
|
||||
inkscape:window-maximized="1"
|
||||
inkscape:current-layer="g9615" />
|
||||
<defs
|
||||
id="defs2475" />
|
||||
<g
|
||||
id="layer1"
|
||||
transform="translate(-71.28524,-137.37328)">
|
||||
<g
|
||||
id="g9615">
|
||||
<g
|
||||
id="g1124">
|
||||
<path
|
||||
id="path41791"
|
||||
style="fill:#ffffff;fill-opacity:1;stroke-width:0.22665;stroke-linecap:round;stroke-linejoin:round"
|
||||
d="m 96.963564,151.38471 23.654566,-13.59708 a 3.1148255,3.1148255 0 0 1 4.66711,2.70047 v 27.80743 a 5.5821378,5.5821378 0 0 1 -2.80027,4.83957 l -23.654571,13.59709 a 3.1148255,3.1148255 0 0 1 -4.667106,-2.70048 v -27.80743 a 5.5821378,5.5821378 0 0 1 2.800271,-4.83957 z" />
|
||||
<path
|
||||
id="path41803"
|
||||
style="display:inline;fill:#45b34f;stroke-width:0.118768;stroke-linecap:round;stroke-linejoin:round"
|
||||
d="m 114.81168,169.4541 5.56851,-3.20545 a 0.09387282,0.09387282 0 0 1 0.14066,0.0782 l 0.0603,1.77975 a 0.19488658,0.19488658 0 0 1 -0.0976,0.17551 l -5.5685,3.20545 a 0.09387286,0.09387286 0 0 1 -0.14066,-0.0782 l -0.0603,-1.77976 a 0.19488664,0.19488664 0 0 1 0.0976,-0.1755 z" />
|
||||
<g
|
||||
id="g1108">
|
||||
<g
|
||||
id="g9585">
|
||||
<path
|
||||
id="path41793"
|
||||
style="fill:#b1bbc0;fill-opacity:1;stroke:none;stroke-width:0.793752;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
d="m 71.285354,146.05562 2.00944,8.127 -1.49302,5.92984 3.92614,3.91052 2.17795,8.80874 11.4956,4.81002 4.76194,4.74298 v -4e-4 -19.06604 0 l -3.84523,-3.82922 -1.11095,4.41624 z" />
|
||||
<g
|
||||
id="g9208">
|
||||
<path
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:0.265;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
d="m 77.905907,172.83169 11.49544,4.81016 -6.147116,-6.12259 z"
|
||||
id="path41799" />
|
||||
<path
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:0.265;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
d="m 94.163216,168.8423 -22.877976,-22.78639 4.442674,17.96707 7.526317,7.49628 z"
|
||||
id="path41801" />
|
||||
</g>
|
||||
</g>
|
||||
<g
|
||||
id="g1090">
|
||||
<g
|
||||
id="g9214">
|
||||
<path
|
||||
id="path41805"
|
||||
style="fill:#3e474b;fill-opacity:1;stroke:none;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
|
||||
d="m 117.04103,146.05561 -2.00944,8.1268 1.49326,5.92985 -3.92634,3.91052 -2.17795,8.80874 -11.495396,4.81022 -4.76176,4.74257 v 0 -19.06603 l 3.84524,-3.82942 1.11094,4.41623 z" />
|
||||
</g>
|
||||
<g
|
||||
id="g1081"
|
||||
transform="translate(-5e-5,-2e-4)">
|
||||
<path
|
||||
style="fill:#515b60;fill-opacity:1;stroke:none;stroke-width:0.265;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
d="m 110.42056,172.83169 -11.495474,4.81016 6.147114,-6.12259 z"
|
||||
id="path41795" />
|
||||
<path
|
||||
style="fill:#515b60;fill-opacity:1;stroke:none;stroke-width:0.265;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
d="m 94.163216,168.8423 22.877974,-22.78639 -4.44263,17.96707 -7.52636,7.49628 z"
|
||||
id="path41797" />
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 4.6 KiB |
@@ -0,0 +1,75 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!-- Created with Inkscape (http://www.inkscape.org/) -->
|
||||
|
||||
<svg
|
||||
width="70.001816mm"
|
||||
height="22.666498mm"
|
||||
viewBox="0 0 70.001816 22.666498"
|
||||
version="1.1"
|
||||
id="svg2478"
|
||||
sodipodi:docname="dark_mode_wordmark_lowercase.svg"
|
||||
inkscape:version="1.1.2 (b8e25be833, 2022-02-05)"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:svg="http://www.w3.org/2000/svg">
|
||||
<sodipodi:namedview
|
||||
id="namedview12"
|
||||
pagecolor="#ffffff"
|
||||
bordercolor="#666666"
|
||||
borderopacity="1.0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:pageopacity="0.0"
|
||||
inkscape:pagecheckerboard="true"
|
||||
inkscape:document-units="mm"
|
||||
showgrid="false"
|
||||
fit-margin-top="0"
|
||||
fit-margin-left="0"
|
||||
fit-margin-right="0"
|
||||
fit-margin-bottom="0"
|
||||
inkscape:zoom="1.9994422"
|
||||
inkscape:cx="123.03431"
|
||||
inkscape:cy="-15.504324"
|
||||
inkscape:window-width="1920"
|
||||
inkscape:window-height="1017"
|
||||
inkscape:window-x="-8"
|
||||
inkscape:window-y="-8"
|
||||
inkscape:window-maximized="1"
|
||||
inkscape:current-layer="svg2478" />
|
||||
<defs
|
||||
id="defs2475" />
|
||||
<g
|
||||
id="g967"
|
||||
transform="translate(-2.2495861,-17.599696)">
|
||||
<g
|
||||
id="g9615"
|
||||
transform="translate(-59.217329,-138.31344)">
|
||||
<g
|
||||
id="g41739"
|
||||
transform="matrix(0.85714226,0,0,0.85714226,-1218.3151,927.76689)"
|
||||
style="display:inline;stroke-width:1.16667">
|
||||
<g
|
||||
id="g41829"
|
||||
style="display:inline"
|
||||
transform="matrix(1.1666675,0,0,1.1666675,-235.22352,200.90935)">
|
||||
<path
|
||||
d="m 1481.5343,-921.52789 v -22.40145 h 11.8268 c 2.2494,0 3.9423,0.53337 5.0786,1.6001 1.1595,1.06674 1.7393,2.57408 1.7393,4.52204 0,1.18268 -0.2319,2.17985 -0.6957,2.99149 -0.4406,0.78846 -1.032,1.40299 -1.7741,1.8436 1.0204,0.37104 1.8204,0.916 2.4002,1.63489 0.5797,0.71889 0.8696,1.79722 0.8696,3.23499 0,2.13347 -0.6261,3.76836 -1.8784,4.90466 -1.2522,1.11312 -3.0494,1.66968 -5.3916,1.66968 z m 4.4993,-13.28782 h 6.8068 c 0.9739,0 1.6812,-0.2203 2.1218,-0.66091 0.4406,-0.44061 0.661,-1.05514 0.661,-1.8436 0,-0.85802 -0.2204,-1.49575 -0.661,-1.91316 -0.4406,-0.44061 -1.2406,-0.66092 -2.4001,-0.66092 h -6.5285 z m 0,9.28756 h 7.3633 c 1.0204,0 1.774,-0.20871 2.261,-0.62613 0.5102,-0.41742 0.7653,-1.15949 0.7653,-2.22623 0,-0.85802 -0.2435,-1.49575 -0.7305,-1.91317 -0.487,-0.4406 -1.3218,-0.66091 -2.5045,-0.66091 h -7.1546 z"
|
||||
id="path41821"
|
||||
style="font-weight:600;font-size:135.945px;line-height:1.25;font-family:Kanit;-inkscape-font-specification:'Kanit Semi-Bold';word-spacing:0px;fill:#ffffff;stroke:#ffffff;stroke-width:0.264583;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
|
||||
<path
|
||||
id="path41823"
|
||||
style="font-weight:600;font-size:135.945px;line-height:1.25;font-family:Kanit;-inkscape-font-specification:'Kanit Semi-Bold';word-spacing:0px;fill:#ffffff;stroke:#ffffff;stroke-width:0.264583;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
d="m 1506.4181,-940.01134 v 3.60332 h 4.173 c 2.6047,0 4.2857,-0.0426 4.4195,1.62757 v 0.87865 c -0.037,0 -0.2304,6.8e-4 -0.3233,8.1e-4 h -2.4927 c 0,0 -0.049,6.8e-4 -0.099,10e-4 -0.3506,-6.8e-4 -0.6995,-10e-4 -1.0639,-0.002 -5.2023,0 -6.9053,2.88353 -7.1561,5.75075 -0.015,5.2321 3.7291,6.56658 7.1561,6.61879 2.1165,-0.009 4.173,0 4.173,0 h 3.9656 v -6.1849 -6.18478 -0.49069 c 0,-4.48165 -2.4644,-5.61832 -7.2996,-5.61832 z m 4.2893,10.10451 h 4.3032 v 2.18928 2.18941 h -1.7445 -2.5587 c -0.9821,0 -1.7058,-0.19377 -2.171,-0.58128 -0.4652,-0.38748 -0.6978,-0.91705 -0.6978,-1.5887 0,-0.007 7e-4,-0.0129 7e-4,-0.0194 h 7e-4 v -0.007 c 0,-0.15019 0.012,-0.29241 0.033,-0.4271 0.079,-0.47856 0.2998,-0.87018 0.6646,-1.17403 0.4652,-0.38751 1.1889,-0.58128 2.171,-0.58128 z" />
|
||||
<path
|
||||
d="m 1528.5277,-921.52789 c -3.1768,-0.15406 -4.4238,-2.60536 -4.3648,-5.87864 v -8.59296 h -2.4895 v -4.01186 h 2.4895 v -3.91799 h 4.0169 v 3.91799 h 4.4177 v 4.01186 h -4.4177 v 8.21032 c 0,0.78846 0.1971,1.48415 0.5914,1.80881 0.3942,0.30147 0.9855,0.45221 1.774,0.45221 l 2.0523,0.006 v 3.99471 z"
|
||||
id="path41825"
|
||||
style="font-weight:600;font-size:135.945px;line-height:1.25;font-family:Kanit;-inkscape-font-specification:'Kanit Semi-Bold';word-spacing:0px;fill:#ffffff;stroke:#ffffff;stroke-width:0.264583;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
|
||||
<path
|
||||
id="path41827"
|
||||
style="fill:#ffffff;stroke:#ffffff;stroke-width:0.264583;stroke-linecap:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
d="m 1543.5776,-940.01134 c -5.3998,0 -7.8157,1.34284 -7.9478,5.27667 0.1079,1.84396 0.6367,3.10179 2.0737,3.96515 h 0.024 c 0.1601,0.0968 0.3347,0.18873 0.5194,0.28834 3.2668,1.76133 7.8402,1.45762 8.1892,3.67678 0,0 0.092,1.20801 -1.2599,1.28157 h -3.1895 -2.7156 -3.6349 v 3.9951 h 3.9693 3.7181 c 5.3998,0 7.8156,-1.34284 7.9478,-5.27667 -0.108,-1.84396 -0.6368,-3.10176 -2.0737,-3.96512 h -0.024 c -0.16,-0.0968 -0.3346,-0.18875 -0.5193,-0.28837 -3.2668,-1.76133 -7.8403,-1.45764 -8.1892,-3.67678 0,0 -0.092,-1.20801 1.2599,-1.28156 h 3.1895 2.7155 3.635 v -3.99511 h -3.9693 z" />
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 5.3 KiB |
@@ -0,0 +1,80 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!-- Created with Inkscape (http://www.inkscape.org/) -->
|
||||
|
||||
<svg
|
||||
width="80.745293mm"
|
||||
height="21.625351mm"
|
||||
viewBox="0 0 80.745293 21.625351"
|
||||
version="1.1"
|
||||
id="svg2478"
|
||||
inkscape:version="1.1.2 (b8e25be833, 2022-02-05)"
|
||||
sodipodi:docname="dark_mode_wordmark_uppercase.svg"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:svg="http://www.w3.org/2000/svg">
|
||||
<sodipodi:namedview
|
||||
id="namedview2480"
|
||||
pagecolor="#ffffff"
|
||||
bordercolor="#666666"
|
||||
borderopacity="1.0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:pageopacity="0.0"
|
||||
inkscape:pagecheckerboard="true"
|
||||
inkscape:document-units="mm"
|
||||
showgrid="false"
|
||||
fit-margin-top="0"
|
||||
fit-margin-left="0"
|
||||
fit-margin-right="0"
|
||||
fit-margin-bottom="0"
|
||||
inkscape:zoom="1.0469406"
|
||||
inkscape:cx="102.20255"
|
||||
inkscape:cy="46.325454"
|
||||
inkscape:window-width="1284"
|
||||
inkscape:window-height="1040"
|
||||
inkscape:window-x="632"
|
||||
inkscape:window-y="71"
|
||||
inkscape:window-maximized="0"
|
||||
inkscape:current-layer="g41739" />
|
||||
<defs
|
||||
id="defs2475" />
|
||||
<g
|
||||
inkscape:label="Layer 1"
|
||||
inkscape:groupmode="layer"
|
||||
id="layer1"
|
||||
transform="translate(-69.238415,-136.04173)">
|
||||
<g
|
||||
id="g9615">
|
||||
<g
|
||||
id="g41739"
|
||||
transform="matrix(0.85714226,0,0,0.85714226,-1218.3151,927.76689)"
|
||||
style="display:inline;stroke-width:1.16667">
|
||||
<g
|
||||
aria-label="BATS"
|
||||
id="g41789"
|
||||
style="font-size:15.875px;line-height:1.25;word-spacing:0px;display:inline;fill:#ffffff;stroke-width:0.128968"
|
||||
transform="matrix(2.3934725,0,0,2.3934725,1452.4353,-1069.4974)"
|
||||
inkscape:export-filename="D:\Art2021\2023\Bats-refined.png"
|
||||
inkscape:export-xdpi="150"
|
||||
inkscape:export-ydpi="150">
|
||||
<path
|
||||
d="m 20.76962,71.305199 v -10.2235 h 5.3975 q 1.539875,0 2.31775,0.73025 0.79375,0.73025 0.79375,2.06375 0,0.809625 -0.3175,1.36525 -0.301625,0.53975 -0.809625,0.841375 0.6985,0.254 1.095375,0.746125 0.396875,0.492125 0.396875,1.476375 0,1.4605 -0.85725,2.238375 -0.85725,0.762 -2.460625,0.762 z m 2.555875,-6.06425 h 2.079625 q 0.66675,0 0.968375,-0.301625 0.301625,-0.301625 0.301625,-0.841375 0,-0.587375 -0.301625,-0.873125 -0.301625,-0.301625 -1.095375,-0.301625 h -1.952625 z m 0,4.238625 h 2.333625 q 0.6985,0 1.031875,-0.28575 0.34925,-0.28575 0.34925,-1.016 0,-0.587375 -0.333375,-0.873125 -0.333375,-0.301625 -1.143,-0.301625 h -2.238375 z"
|
||||
style="font-weight:600;font-family:Kanit;-inkscape-font-specification:'Kanit Semi-Bold';stroke-width:0.128968"
|
||||
id="path41781" />
|
||||
<path
|
||||
d="m 31.152168,71.305199 3.90525,-10.2235 h 2.76225 l 3.90525,10.2235 h -2.667 l -0.92075,-2.31775 h -3.413125 l -0.904875,2.31775 z m 3.921125,-4.206875 h 2.714625 l -1.36525,-3.556 z"
|
||||
style="font-weight:600;font-family:Kanit;-inkscape-font-specification:'Kanit Semi-Bold';stroke-width:0.128968"
|
||||
id="path41783" />
|
||||
<path
|
||||
d="m 44.89475,71.305199 v -8.255 h -3.000375 v -1.9685 H 50.451 v 1.9685 h -3.000375 v 8.255 z"
|
||||
style="font-weight:600;font-family:Kanit;-inkscape-font-specification:'Kanit Semi-Bold';stroke-width:0.128968"
|
||||
id="path41785" />
|
||||
<path
|
||||
d="m 55.873376,71.463949 q -1.016,0 -1.905,-0.15875 -0.873125,-0.142875 -1.508125,-0.428625 v -2.174875 q 0.6985,0.301625 1.539875,0.492125 0.85725,0.1905 1.61925,0.1905 0.9525,0 1.412875,-0.174625 0.47625,-0.174625 0.47625,-0.762 0,-0.396875 -0.238125,-0.635 -0.22225,-0.238125 -0.746125,-0.41275 -0.508,-0.1905 -1.397,-0.4445 -1.04775,-0.3175 -1.666875,-0.6985 -0.619125,-0.396875 -0.889,-0.9525 -0.269875,-0.555625 -0.269875,-1.36525 0,-1.4605 1.04775,-2.238375 1.04775,-0.777875 3.095625,-0.777875 0.889,0 1.730375,0.142875 0.841375,0.127 1.36525,0.301625 v 2.19075 q -0.682625,-0.269875 -1.381125,-0.396875 -0.682625,-0.127 -1.3335,-0.127 -0.85725,0 -1.397,0.15875 -0.523875,0.15875 -0.523875,0.73025 0,0.333375 0.1905,0.53975 0.1905,0.1905 0.650875,0.34925 0.47625,0.15875 1.285875,0.381 1.254125,0.333375 1.920875,0.809625 0.66675,0.460375 0.92075,1.0795 0.254,0.60325 0.254,1.36525 0,1.349375 -1.04775,2.19075 -1.04775,0.8255 -3.20675,0.8255 z"
|
||||
style="font-weight:600;font-family:Kanit;-inkscape-font-specification:'Kanit Semi-Bold';stroke-width:0.128968"
|
||||
id="path41787" />
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 4.5 KiB |
@@ -0,0 +1,99 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!-- Created with Inkscape (http://www.inkscape.org/) -->
|
||||
|
||||
<svg
|
||||
width="54.261147mm"
|
||||
height="43.081844mm"
|
||||
viewBox="0 0 54.261147 43.081844"
|
||||
version="1.1"
|
||||
id="svg2478"
|
||||
inkscape:version="1.1.2 (b8e25be833, 2022-02-05)"
|
||||
sodipodi:docname="light_mode_bat.svg"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:svg="http://www.w3.org/2000/svg">
|
||||
<sodipodi:namedview
|
||||
id="namedview2480"
|
||||
pagecolor="#ffffff"
|
||||
bordercolor="#666666"
|
||||
borderopacity="1.0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:pageopacity="0.0"
|
||||
inkscape:pagecheckerboard="true"
|
||||
inkscape:document-units="mm"
|
||||
showgrid="false"
|
||||
fit-margin-top="0"
|
||||
fit-margin-left="0"
|
||||
fit-margin-right="0"
|
||||
fit-margin-bottom="0"
|
||||
inkscape:zoom="1.0469406"
|
||||
inkscape:cx="95.5164"
|
||||
inkscape:cy="32.953158"
|
||||
inkscape:window-width="1284"
|
||||
inkscape:window-height="1040"
|
||||
inkscape:window-x="632"
|
||||
inkscape:window-y="71"
|
||||
inkscape:window-maximized="0"
|
||||
inkscape:current-layer="g41739" />
|
||||
<defs
|
||||
id="defs2475" />
|
||||
<g
|
||||
inkscape:label="Layer 1"
|
||||
inkscape:groupmode="layer"
|
||||
id="layer1"
|
||||
transform="translate(-71.195776,-139.44713)">
|
||||
<g
|
||||
id="g9615">
|
||||
<g
|
||||
id="g41739"
|
||||
transform="matrix(0.85714226,0,0,0.85714226,-1218.3151,927.76689)"
|
||||
style="display:inline;stroke-width:1.16667">
|
||||
<g
|
||||
id="g24595"
|
||||
transform="matrix(1.8087061,0,0,1.8087061,-1236.9066,713.01919)"
|
||||
style="stroke-width:0.64503">
|
||||
<path
|
||||
style="fill:#3e474b;fill-opacity:1;stroke:none;stroke-width:0.51199;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
d="m 1533.1344,-889.4993 2.9413,-2.92919 0.8498,3.37817 13.7088,-13.65367 -1.5371,6.21648 1.1421,4.5359 -3.0032,2.99127 -1.666,6.73802 -8.7932,3.67943 -3.6425,3.62793 -3.6425,-3.62793 -8.7932,-3.67943 -1.666,-6.73802 -3.0033,-2.99127 1.1421,-4.5359 -1.537,-6.21648 13.7088,13.65367 0.8498,-3.37817 z"
|
||||
id="path41727"
|
||||
inkscape:export-filename="D:\Art2021\2023\BatsLogo\test.png"
|
||||
inkscape:export-xdpi="150"
|
||||
inkscape:export-ydpi="150" />
|
||||
<g
|
||||
id="g41737"
|
||||
style="fill:#515b60;fill-opacity:1;stroke-width:0.64503">
|
||||
<path
|
||||
style="fill:#515b60;fill-opacity:1;stroke:none;stroke-width:0.170933;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
d="m 1545.57,-882.22245 -8.7932,3.67942 4.7021,-4.68334 z"
|
||||
id="path41729"
|
||||
inkscape:export-filename="D:\Art2021\2023\BatsLogo\test.png"
|
||||
inkscape:export-xdpi="150"
|
||||
inkscape:export-ydpi="150" />
|
||||
<path
|
||||
style="fill:#515b60;fill-opacity:1;stroke:none;stroke-width:0.170933;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
d="m 1533.1343,-885.27404 17.5,-17.42995 -3.3983,13.74351 -5.7571,5.73411 z"
|
||||
id="path41731"
|
||||
inkscape:export-filename="D:\Art2021\2023\BatsLogo\test.png"
|
||||
inkscape:export-xdpi="150"
|
||||
inkscape:export-ydpi="150" />
|
||||
<path
|
||||
style="fill:#515b60;fill-opacity:1;stroke:none;stroke-width:0.170933;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
d="m 1520.6986,-882.22245 8.7932,3.67942 -4.7021,-4.68334 z"
|
||||
id="path41733"
|
||||
inkscape:export-filename="D:\Art2021\2023\BatsLogo\test.png"
|
||||
inkscape:export-xdpi="150"
|
||||
inkscape:export-ydpi="150" />
|
||||
<path
|
||||
style="fill:#515b60;fill-opacity:1;stroke:none;stroke-width:0.170933;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
d="m 1533.1343,-885.27404 -17.5,-17.42995 3.3983,13.74351 5.7571,5.73411 z"
|
||||
id="path41735"
|
||||
inkscape:export-filename="D:\Art2021\2023\BatsLogo\test.png"
|
||||
inkscape:export-xdpi="150"
|
||||
inkscape:export-ydpi="150" />
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 4.4 KiB |
@@ -0,0 +1,90 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!-- Created with Inkscape (http://www.inkscape.org/) -->
|
||||
|
||||
<svg
|
||||
width="54mm"
|
||||
height="49.773262mm"
|
||||
viewBox="0 0 54 49.773262"
|
||||
version="1.1"
|
||||
id="svg2478"
|
||||
sodipodi:docname="light_mode_cube.svg"
|
||||
inkscape:version="1.1.2 (b8e25be833, 2022-02-05)"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:svg="http://www.w3.org/2000/svg">
|
||||
<sodipodi:namedview
|
||||
id="namedview22"
|
||||
pagecolor="#ffffff"
|
||||
bordercolor="#666666"
|
||||
borderopacity="1.0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:pageopacity="0.0"
|
||||
inkscape:pagecheckerboard="0"
|
||||
inkscape:document-units="mm"
|
||||
showgrid="false"
|
||||
inkscape:zoom="3.1235784"
|
||||
inkscape:cx="81.797212"
|
||||
inkscape:cy="86.439323"
|
||||
inkscape:window-width="1920"
|
||||
inkscape:window-height="1017"
|
||||
inkscape:window-x="-8"
|
||||
inkscape:window-y="-8"
|
||||
inkscape:window-maximized="1"
|
||||
inkscape:current-layer="svg2478" />
|
||||
<defs
|
||||
id="defs2475" />
|
||||
<g
|
||||
id="g1227">
|
||||
<path
|
||||
id="path41791"
|
||||
style="fill:#3e474b;fill-opacity:1;stroke-width:0.22665;stroke-linecap:round;stroke-linejoin:round"
|
||||
d="M 25.678324,14.01143 49.33289,0.41435 A 3.1148255,3.1148255 0 0 1 54,3.11482 v 27.80743 a 5.5821378,5.5821378 0 0 1 -2.80027,4.83957 L 27.545159,49.35891 A 3.1148255,3.1148255 0 0 1 22.878053,46.65843 V 18.851 a 5.5821378,5.5821378 0 0 1 2.800271,-4.83957 z" />
|
||||
<path
|
||||
id="path41803"
|
||||
style="display:inline;fill:#45b34f;stroke-width:0.118768;stroke-linecap:round;stroke-linejoin:round"
|
||||
d="m 43.52644,32.08082 5.56851,-3.20545 a 0.09387282,0.09387282 0 0 1 0.14066,0.0782 l 0.0603,1.77975 a 0.19488658,0.19488658 0 0 1 -0.0976,0.17551 l -5.5685,3.20545 a 0.09387286,0.09387286 0 0 1 -0.14066,-0.0782 l -0.0603,-1.77976 a 0.19488664,0.19488664 0 0 1 0.0976,-0.1755 z" />
|
||||
<g
|
||||
id="g1212">
|
||||
<g
|
||||
id="g9585"
|
||||
transform="translate(-71.28524,-137.37328)">
|
||||
<path
|
||||
id="path41793"
|
||||
style="fill:#3e474b;fill-opacity:1;stroke:none;stroke-width:0.793752;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
d="m 71.285354,146.05562 2.00944,8.127 -1.49302,5.92984 3.92614,3.91052 2.17795,8.80874 11.4956,4.81002 4.76194,4.74298 v -4e-4 -19.06604 0 l -3.84523,-3.82922 -1.11095,4.41624 z" />
|
||||
<g
|
||||
id="g9208">
|
||||
<path
|
||||
style="fill:#515b60;fill-opacity:1;stroke:none;stroke-width:0.265;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
d="m 77.905907,172.83169 11.49544,4.81016 -6.147116,-6.12259 z"
|
||||
id="path41799" />
|
||||
<path
|
||||
style="fill:#515b60;fill-opacity:1;stroke:none;stroke-width:0.265;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
d="m 94.163216,168.8423 -22.877976,-22.78639 4.442674,17.96707 7.526317,7.49628 z"
|
||||
id="path41801" />
|
||||
</g>
|
||||
</g>
|
||||
<g
|
||||
id="g9214"
|
||||
transform="translate(-71.28524,-137.37328)">
|
||||
<path
|
||||
id="path41805"
|
||||
style="fill:#b1bbc0;fill-opacity:1;stroke:none;stroke-width:0.264583px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1"
|
||||
d="m 117.04096,146.05572 -2.00944,8.1268 1.49326,5.92985 -3.92634,3.91052 -2.17795,8.80874 -11.495404,4.81022 -4.761755,4.74257 v 0 -19.06603 l 3.845235,-3.82942 1.110946,4.41623 z" />
|
||||
<g
|
||||
id="g9204"
|
||||
style="fill:#ffffff;fill-opacity:1">
|
||||
<path
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:0.265;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
d="m 110.42056,172.83169 -11.495474,4.81016 6.147114,-6.12259 z"
|
||||
id="path41807" />
|
||||
<path
|
||||
style="fill:#ffffff;fill-opacity:1;stroke:none;stroke-width:0.265;stroke-linecap:round;stroke-linejoin:bevel;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
d="m 94.163216,168.8423 22.877974,-22.78639 -4.44263,17.96707 -7.52636,7.49628 z"
|
||||
id="path41809" />
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 4.3 KiB |
@@ -0,0 +1,79 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!-- Created with Inkscape (http://www.inkscape.org/) -->
|
||||
|
||||
<svg
|
||||
width="70.001816mm"
|
||||
height="22.666498mm"
|
||||
viewBox="0 0 70.001816 22.666498"
|
||||
version="1.1"
|
||||
id="svg2478"
|
||||
inkscape:version="1.1.2 (b8e25be833, 2022-02-05)"
|
||||
sodipodi:docname="wordmark_lowercase_dark.svg"
|
||||
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
|
||||
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:svg="http://www.w3.org/2000/svg">
|
||||
<sodipodi:namedview
|
||||
id="namedview2480"
|
||||
pagecolor="#ffffff"
|
||||
bordercolor="#666666"
|
||||
borderopacity="1.0"
|
||||
inkscape:pageshadow="2"
|
||||
inkscape:pageopacity="0.0"
|
||||
inkscape:pagecheckerboard="true"
|
||||
inkscape:document-units="mm"
|
||||
showgrid="false"
|
||||
fit-margin-top="0"
|
||||
fit-margin-left="0"
|
||||
fit-margin-right="0"
|
||||
fit-margin-bottom="0"
|
||||
inkscape:zoom="1.0469406"
|
||||
inkscape:cx="115.57484"
|
||||
inkscape:cy="-0.477582"
|
||||
inkscape:window-width="1284"
|
||||
inkscape:window-height="1040"
|
||||
inkscape:window-x="632"
|
||||
inkscape:window-y="71"
|
||||
inkscape:window-maximized="0"
|
||||
inkscape:current-layer="g41739" />
|
||||
<defs
|
||||
id="defs2475" />
|
||||
<g
|
||||
inkscape:label="Layer 1"
|
||||
inkscape:groupmode="layer"
|
||||
id="layer1"
|
||||
transform="translate(-65.637684,-148.3707)">
|
||||
<g
|
||||
id="g9615">
|
||||
<g
|
||||
id="g41739"
|
||||
transform="matrix(0.85714226,0,0,0.85714226,-1218.3151,927.76689)"
|
||||
style="display:inline;stroke-width:1.16667">
|
||||
<g
|
||||
id="g41939"
|
||||
transform="matrix(1.1666675,0,0,1.1666675,-230.35762,192.10983)"
|
||||
style="display:inline;fill:#3e474b;fill-opacity:1;stroke:#3e474b;stroke-opacity:1">
|
||||
<path
|
||||
d="m 1481.5343,-921.52789 v -22.40145 h 11.8268 c 2.2494,0 3.9423,0.53337 5.0786,1.6001 1.1595,1.06674 1.7393,2.57408 1.7393,4.52204 0,1.18268 -0.2319,2.17985 -0.6957,2.99149 -0.4406,0.78846 -1.032,1.40299 -1.7741,1.8436 1.0204,0.37104 1.8204,0.916 2.4002,1.63489 0.5797,0.71889 0.8696,1.79722 0.8696,3.23499 0,2.13347 -0.6261,3.76836 -1.8784,4.90466 -1.2522,1.11312 -3.0494,1.66968 -5.3916,1.66968 z m 4.4993,-13.28782 h 6.8068 c 0.9739,0 1.6812,-0.2203 2.1218,-0.66091 0.4406,-0.44061 0.661,-1.05514 0.661,-1.8436 0,-0.85802 -0.2204,-1.49575 -0.661,-1.91316 -0.4406,-0.44061 -1.2406,-0.66092 -2.4001,-0.66092 h -6.5285 z m 0,9.28756 h 7.3633 c 1.0204,0 1.774,-0.20871 2.261,-0.62613 0.5102,-0.41742 0.7653,-1.15949 0.7653,-2.22623 0,-0.85802 -0.2435,-1.49575 -0.7305,-1.91317 -0.487,-0.4406 -1.3218,-0.66091 -2.5045,-0.66091 h -7.1546 z"
|
||||
id="path41931"
|
||||
sodipodi:nodetypes="ccscsccsscsccssscscccscscscc"
|
||||
style="font-weight:600;font-size:135.945px;line-height:1.25;font-family:Kanit;-inkscape-font-specification:'Kanit Semi-Bold';word-spacing:0px;fill:#3e474b;fill-opacity:1;stroke:#3e474b;stroke-width:0.264583;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
|
||||
<path
|
||||
id="path41933"
|
||||
style="font-weight:600;font-size:135.945px;line-height:1.25;font-family:Kanit;-inkscape-font-specification:'Kanit Semi-Bold';word-spacing:0px;fill:#3e474b;fill-opacity:1;stroke:#3e474b;stroke-width:0.264583;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
d="m 1506.4181,-940.01134 v 3.60332 h 4.173 c 2.6047,0 4.2857,-0.0426 4.4195,1.62757 v 0.87865 c -0.037,0 -0.2304,6.8e-4 -0.3233,8.1e-4 h -2.4927 c 0,0 -0.049,6.8e-4 -0.099,10e-4 -0.3506,-6.8e-4 -0.6995,-10e-4 -1.0639,-0.002 -5.2023,0 -6.9053,2.88353 -7.1561,5.75075 -0.015,5.2321 3.7291,6.56658 7.1561,6.61879 2.1165,-0.009 4.173,0 4.173,0 h 3.9656 v -6.1849 -6.18478 -0.49069 c 0,-4.48165 -2.4644,-5.61832 -7.2996,-5.61832 z m 4.2893,10.10451 h 4.3032 v 2.18928 2.18941 h -1.7445 -2.5587 c -0.9821,0 -1.7058,-0.19377 -2.171,-0.58128 -0.4652,-0.38748 -0.6978,-0.91705 -0.6978,-1.5887 0,-0.007 7e-4,-0.0129 7e-4,-0.0194 h 7e-4 v -0.007 c 0,-0.15019 0.012,-0.29241 0.033,-0.4271 0.079,-0.47856 0.2998,-0.87018 0.6646,-1.17403 0.4652,-0.38751 1.1889,-0.58128 2.171,-0.58128 z"
|
||||
sodipodi:nodetypes="ccsccccccccccccscccccccsssccccscc" />
|
||||
<path
|
||||
d="m 1528.5277,-921.52789 c -3.1768,-0.15406 -4.4238,-2.60536 -4.3648,-5.87864 v -8.59296 h -2.4895 v -4.01186 h 2.4895 v -3.91799 h 4.0169 v 3.91799 h 4.4177 v 4.01186 h -4.4177 v 8.21032 c 0,0.78846 0.1971,1.48415 0.5914,1.80881 0.3942,0.30147 0.9855,0.45221 1.774,0.45221 l 2.0523,0.006 v 3.99471 z"
|
||||
id="path41935"
|
||||
style="font-weight:600;font-size:135.945px;line-height:1.25;font-family:Kanit;-inkscape-font-specification:'Kanit Semi-Bold';word-spacing:0px;fill:#3e474b;fill-opacity:1;stroke:#3e474b;stroke-width:0.264583;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
sodipodi:nodetypes="ccccccccccccscsccc" />
|
||||
<path
|
||||
id="path41937"
|
||||
style="fill:#3e474b;fill-opacity:1;stroke:#3e474b;stroke-width:0.264583;stroke-linecap:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1"
|
||||
d="m 1543.5776,-940.01134 c -5.3998,0 -7.8157,1.34284 -7.9478,5.27667 0.1079,1.84396 0.6367,3.10179 2.0737,3.96515 h 0.024 c 0.1601,0.0968 0.3347,0.18873 0.5194,0.28834 3.2668,1.76133 7.8402,1.45762 8.1892,3.67678 0,0 0.092,1.20801 -1.2599,1.28157 h -3.1895 -2.7156 -3.6349 v 3.9951 h 3.9693 3.7181 c 5.3998,0 7.8156,-1.34284 7.9478,-5.27667 -0.108,-1.84396 -0.6368,-3.10176 -2.0737,-3.96512 h -0.024 c -0.16,-0.0968 -0.3346,-0.18875 -0.5193,-0.28837 -3.2668,-1.76133 -7.8403,-1.45764 -8.1892,-3.67678 0,0 -0.092,-1.20801 1.2599,-1.28156 h 3.1895 2.7155 3.635 v -3.99511 h -3.9693 z" />
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 5.6 KiB |
@@ -0,0 +1,48 @@
|
||||
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
|
||||
<!-- Created with Inkscape (http://www.inkscape.org/) -->
|
||||
|
||||
<svg
|
||||
width="80.745293mm"
|
||||
height="21.625351mm"
|
||||
viewBox="0 0 80.745293 21.625351"
|
||||
version="1.1"
|
||||
id="svg2478"
|
||||
xmlns="http://www.w3.org/2000/svg"
|
||||
xmlns:svg="http://www.w3.org/2000/svg">
|
||||
<defs
|
||||
id="defs2475" />
|
||||
<g
|
||||
id="layer1"
|
||||
transform="translate(-69.301072,-141.15047)">
|
||||
<g
|
||||
id="g9615">
|
||||
<g
|
||||
id="g41739"
|
||||
transform="matrix(0.85714226,0,0,0.85714226,-1218.3151,927.76689)"
|
||||
style="display:inline;stroke-width:1.16667">
|
||||
<g
|
||||
aria-label="BATS"
|
||||
id="g41869"
|
||||
style="font-size:15.875px;line-height:1.25;word-spacing:0px;display:inline;fill:#3e474b;fill-opacity:1;stroke-width:0.128968"
|
||||
transform="matrix(2.3934725,0,0,2.3934725,1452.5084,-1063.5372)">
|
||||
<path
|
||||
d="m 20.76962,71.305199 v -10.2235 h 5.3975 q 1.539875,0 2.31775,0.73025 0.79375,0.73025 0.79375,2.06375 0,0.809625 -0.3175,1.36525 -0.301625,0.53975 -0.809625,0.841375 0.6985,0.254 1.095375,0.746125 0.396875,0.492125 0.396875,1.476375 0,1.4605 -0.85725,2.238375 -0.85725,0.762 -2.460625,0.762 z m 2.555875,-6.06425 h 2.079625 q 0.66675,0 0.968375,-0.301625 0.301625,-0.301625 0.301625,-0.841375 0,-0.587375 -0.301625,-0.873125 -0.301625,-0.301625 -1.095375,-0.301625 h -1.952625 z m 0,4.238625 h 2.333625 q 0.6985,0 1.031875,-0.28575 0.34925,-0.28575 0.34925,-1.016 0,-0.587375 -0.333375,-0.873125 -0.333375,-0.301625 -1.143,-0.301625 h -2.238375 z"
|
||||
style="font-weight:600;font-family:Kanit;-inkscape-font-specification:'Kanit Semi-Bold';fill:#3e474b;fill-opacity:1;stroke-width:0.128968"
|
||||
id="path41861" />
|
||||
<path
|
||||
d="m 31.152168,71.305199 3.90525,-10.2235 h 2.76225 l 3.90525,10.2235 h -2.667 l -0.92075,-2.31775 h -3.413125 l -0.904875,2.31775 z m 3.921125,-4.206875 h 2.714625 l -1.36525,-3.556 z"
|
||||
style="font-weight:600;font-family:Kanit;-inkscape-font-specification:'Kanit Semi-Bold';fill:#3e474b;fill-opacity:1;stroke-width:0.128968"
|
||||
id="path41863" />
|
||||
<path
|
||||
d="m 44.89475,71.305199 v -8.255 h -3.000375 v -1.9685 H 50.451 v 1.9685 h -3.000375 v 8.255 z"
|
||||
style="font-weight:600;font-family:Kanit;-inkscape-font-specification:'Kanit Semi-Bold';fill:#3e474b;fill-opacity:1;stroke-width:0.128968"
|
||||
id="path41865" />
|
||||
<path
|
||||
d="m 55.873376,71.463949 q -1.016,0 -1.905,-0.15875 -0.873125,-0.142875 -1.508125,-0.428625 v -2.174875 q 0.6985,0.301625 1.539875,0.492125 0.85725,0.1905 1.61925,0.1905 0.9525,0 1.412875,-0.174625 0.47625,-0.174625 0.47625,-0.762 0,-0.396875 -0.238125,-0.635 -0.22225,-0.238125 -0.746125,-0.41275 -0.508,-0.1905 -1.397,-0.4445 -1.04775,-0.3175 -1.666875,-0.6985 -0.619125,-0.396875 -0.889,-0.9525 -0.269875,-0.555625 -0.269875,-1.36525 0,-1.4605 1.04775,-2.238375 1.04775,-0.777875 3.095625,-0.777875 0.889,0 1.730375,0.142875 0.841375,0.127 1.36525,0.301625 v 2.19075 q -0.682625,-0.269875 -1.381125,-0.396875 -0.682625,-0.127 -1.3335,-0.127 -0.85725,0 -1.397,0.15875 -0.523875,0.15875 -0.523875,0.73025 0,0.333375 0.1905,0.53975 0.1905,0.1905 0.650875,0.34925 0.47625,0.15875 1.285875,0.381 1.254125,0.333375 1.920875,0.809625 0.66675,0.460375 0.92075,1.0795 0.254,0.60325 0.254,1.36525 0,1.349375 -1.04775,2.19075 -1.04775,0.8255 -3.20675,0.8255 z"
|
||||
style="font-weight:600;font-family:Kanit;-inkscape-font-specification:'Kanit Semi-Bold';fill:#3e474b;fill-opacity:1;stroke-width:0.128968"
|
||||
id="path41867" />
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</g>
|
||||
</svg>
|
||||
|
After Width: | Height: | Size: 3.6 KiB |
@@ -0,0 +1,74 @@
|
||||
# Configuration file for the Sphinx documentation builder.
|
||||
#
|
||||
# This file only contains a selection of the most common options. For a full
|
||||
# list see the documentation:
|
||||
# https://www.sphinx-doc.org/en/master/usage/configuration.html
|
||||
|
||||
# -- Path setup --------------------------------------------------------------
|
||||
|
||||
# If extensions (or modules to document with autodoc) are in another directory,
|
||||
# add these directories to sys.path here. If the directory is relative to the
|
||||
# documentation root, use os.path.abspath to make it absolute, like shown here.
|
||||
#
|
||||
# import os
|
||||
# import sys
|
||||
# sys.path.insert(0, os.path.abspath('.'))
|
||||
|
||||
|
||||
# -- Project information -----------------------------------------------------
|
||||
|
||||
project = 'bats-core'
|
||||
copyright = '2022, bats-core organization'
|
||||
author = 'bats-core organization'
|
||||
|
||||
# The full version, including alpha/beta/rc tags
|
||||
release = '1'
|
||||
|
||||
|
||||
# -- General configuration ---------------------------------------------------
|
||||
|
||||
# Add any Sphinx extension module names here, as strings. They can be
|
||||
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
|
||||
# ones.
|
||||
extensions = [
|
||||
'recommonmark',
|
||||
'sphinxcontrib.programoutput',
|
||||
'sphinx.ext.autosectionlabel'
|
||||
]
|
||||
|
||||
# Add any paths that contain templates here, relative to this directory.
|
||||
templates_path = ['_templates']
|
||||
|
||||
html_sidebars = { '**': [
|
||||
'about.html',
|
||||
'navigation.html',
|
||||
'relations.html',
|
||||
'searchbox.html',
|
||||
'donate.html'] }
|
||||
|
||||
# List of patterns, relative to source directory, that match files and
|
||||
# directories to ignore when looking for source files.
|
||||
# This pattern also affects html_static_path and html_extra_path.
|
||||
exclude_patterns = []
|
||||
|
||||
|
||||
# -- Options for HTML output -------------------------------------------------
|
||||
|
||||
# The theme to use for HTML and HTML Help pages. See the documentation for
|
||||
# a list of builtin themes.
|
||||
#
|
||||
#html_theme = 'alabaster'
|
||||
|
||||
# Add any paths that contain custom static files (such as style sheets) here,
|
||||
# relative to this directory. They are copied after the builtin static files,
|
||||
# so a file named "default.css" will overwrite the builtin "default.css".
|
||||
html_static_path = ['_static', 'assets']
|
||||
html_logo = "assets/light_mode_cube.svg"
|
||||
|
||||
#man_pages = [ ('man.1', 'bats', 'bats documentation', ['bats-core Contributors'], 1)]
|
||||
|
||||
def setup(app):
|
||||
app.add_config_value('recommonmark_config', {'enable_eval_rst': True}, True)
|
||||
import recommonmark
|
||||
from recommonmark.transform import AutoStructify
|
||||
app.add_transform(AutoStructify)
|
||||
@@ -0,0 +1,70 @@
|
||||
# Docker Usage Guide
|
||||
|
||||
- [Docker Usage Guide](#docker-usage-guide)
|
||||
* [Basic Usage](#basic-usage)
|
||||
* [Basic Usage for bats project](#basic-usage-for-bats-project)
|
||||
* [Docker Gotchas](#docker-gotchas)
|
||||
* [Extending from the base image](#extending-from-the-base-image)
|
||||
|
||||
## Basic Usage
|
||||
|
||||
For test suites that are intended to run in isolation from their project code, you can mount the test directory and run the [official bats docker image](https://hub.docker.com/r/bats/bats):
|
||||
|
||||
```bash
|
||||
$ docker run -it -v "$PWD:/code" bats/bats:latest /code/test
|
||||
```
|
||||
|
||||
This Docker image includes libraries like [bats-support](https://github.com/bats-core/bats-support) and [bats-assert](https://github.com/bats-core/bats-assert), which can be loaded in `setup` like this:
|
||||
|
||||
```bash
|
||||
setup() {
|
||||
bats_load_library bats-support
|
||||
bats_load_library bats-assert
|
||||
}
|
||||
```
|
||||
|
||||
## Basic Usage for Bats Project
|
||||
|
||||
To build and run `bats`' own tests:
|
||||
```bash
|
||||
$ git clone https://github.com/bats-core/bats-core.git
|
||||
Cloning into 'bats-core'...
|
||||
remote: Counting objects: 1222, done.
|
||||
remote: Compressing objects: 100% (53/53), done.
|
||||
remote: Total 1222 (delta 34), reused 55 (delta 21), pack-reused 1146
|
||||
Receiving objects: 100% (1222/1222), 327.28 KiB | 1.70 MiB/s, done.
|
||||
Resolving deltas: 100% (661/661), done.
|
||||
|
||||
$ cd bats-core/
|
||||
$ docker build --tag bats/bats:latest .
|
||||
...
|
||||
$ docker run -it bats/bats:latest --formatter tap /opt/bats/test
|
||||
```
|
||||
|
||||
To mount your tests into the container, first build the image as above. Then, for example with `bats`:
|
||||
```bash
|
||||
$ docker run -it -v "$PWD:/opt/bats" bats/bats:latest /opt/bats/test
|
||||
```
|
||||
This runs the `test/` directory from the bats-core repository inside the bats Docker container.
|
||||
|
||||
## Docker Gotchas
|
||||
|
||||
Relying on functionality provided by your environment (ssh keys or agent, installed binaries, fixtures outside the mounted test directory) will fail when running inside Docker.
|
||||
|
||||
`--interactive`/`-i` attaches an interactive terminal and is useful to kill hanging processes (otherwise has to be done via docker stop command). `--tty`/`-t` simulates a tty (often not used, but most similar to test runs from a Bash prompt). Interactivity is important to a user, but not a build, and TTYs are probably more important to a headless build. Everything's least-surprising to a new Docker use if both are used.
|
||||
|
||||
## Extending from the base image
|
||||
|
||||
Docker operates on a principle of isolation, and bundles all dependencies required into the Docker image. These can be mounted in at runtime (for test files, configuration, etc). For binary dependencies it may be better to extend the base Docker image with further tools and files.
|
||||
|
||||
```dockerfile
|
||||
FROM bats/bats
|
||||
|
||||
RUN \
|
||||
apk \
|
||||
--no-cache \
|
||||
--update \
|
||||
add \
|
||||
openssh
|
||||
|
||||
```
|
||||
@@ -0,0 +1,172 @@
|
||||
FAQ
|
||||
===
|
||||
|
||||
How do I set the working directory?
|
||||
-----------------------------------
|
||||
|
||||
The working directory is simply the directory where you started when executing bats.
|
||||
If you want to enforce a specific directory, you can use `cd` in the `setup_file`/`setup` functions.
|
||||
However, be aware that code outside any function will run before any of these setup functions and might interfere with bats' internals.
|
||||
|
||||
|
||||
How do I see the output of the command under `run` when a test fails?
|
||||
---------------------------------------------------------------------
|
||||
|
||||
`run` captures stdout and stderr of its command and stores it in the `$output` and `${lines[@]}` variables.
|
||||
If you want to see this output, you need to print it yourself, or use functions like `assert_output` that will reproduce it on failure.
|
||||
|
||||
Can I use `--filter` to exclude files/tests?
|
||||
--------------------------------------------
|
||||
|
||||
No, not directly. `--filter` uses a regex to match against test names. So you could try to invert the regex.
|
||||
The filename won't be part of the strings that are tested, so you cannot filter against files.
|
||||
|
||||
How can I exclude a single test from a test run?
|
||||
------------------------------------------------
|
||||
|
||||
If you want to exclude only few tests from a run, you can either `skip` them:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@test "Testname" {
|
||||
# yadayada
|
||||
}
|
||||
|
||||
becomes
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@test "Testname" {
|
||||
skip 'Optional skip message'
|
||||
# yadayada
|
||||
}
|
||||
|
||||
or comment them out, e.g.:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@test "Testname" {
|
||||
|
||||
becomes
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
disabled() { # @test "Testname" {
|
||||
|
||||
For multiple tests or all tests of a file, this becomes tedious, so read on.
|
||||
|
||||
How can I exclude all tests of a file from a test run?
|
||||
--------------------------------------------------------
|
||||
|
||||
If you run your test suite by naming individual files like:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ bats test/a.bats test/b.bats ...
|
||||
|
||||
you can simply omit your file. When running a folder like
|
||||
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ bats test/
|
||||
|
||||
you can prevent test files from being picked up by changing their extension to something other than `.bats`.
|
||||
|
||||
It is also possible to `skip` in `setup_file`/`setup` which will skip all tests in the file.
|
||||
|
||||
How can I include my own `.sh` files for testing?
|
||||
-------------------------------------------------
|
||||
|
||||
You can simply `source <your>.sh` files. However, be aware that `source`ing files with errors outside of any function (or inside `setup_file`) will trip up bats
|
||||
and lead to hard to diagnose errors.
|
||||
Therefore, it is safest to only `source` inside `setup` or the test functions themselves.
|
||||
|
||||
How can I debug a failing test?
|
||||
-------------------------------
|
||||
|
||||
Short of using a bash debugger you should make sure to use appropriate asserts for your task instead of raw bash comparisons, e.g.:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@test test {
|
||||
run echo test failed
|
||||
assert_output "test"
|
||||
# instead of
|
||||
[ "$output" = "test" ]
|
||||
}
|
||||
|
||||
Because the former will print the output when the test fails while the latter won't.
|
||||
Similarly, you should use `assert_success`/`assert_failure` instead of `[ "$status" -eq 0 ]` for return code checks.
|
||||
|
||||
Is there a mechanism to add file/test specific functionality to a common setup function?
|
||||
----------------------------------------------------------------------------------------
|
||||
|
||||
Often the setup consists of parts that are common between different files of a test suite and parts that are specific to each file.
|
||||
There is no suite wide setup functionality yet, so you should extract these common setup steps into their own file (e.g. `common-test-setup.sh`) and function (e.g. `commonSetup() {}`),
|
||||
which can be `source`d or `load`ed and call it in `setup_file` or `setup`.
|
||||
|
||||
How can I use helper libraries like bats-assert?
|
||||
------------------------------------------------
|
||||
|
||||
This is a short reproduction of https://github.com/ztombol/bats-docs.
|
||||
|
||||
At first, you should make sure the library is installed. This is usually done in the `test_helper/` folders alongside the `.bats` files, giving you a filesystem layout like this:
|
||||
|
||||
.. code-block::
|
||||
|
||||
test/
|
||||
test.bats
|
||||
test_helper/
|
||||
bats-support/
|
||||
bats-assert/
|
||||
|
||||
Next, you should load those helper libraries:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
setup() {
|
||||
load 'test_helper/bats-support/load' # this is required by bats-assert!
|
||||
load 'test_helper/bats-assert/load'
|
||||
}
|
||||
|
||||
Now, you should be able to use the functions from these helpers inside your tests, e.g.:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@test "test" {
|
||||
run echo test
|
||||
assert_output "test"
|
||||
}
|
||||
|
||||
Note that you obviously need to load the library before using it.
|
||||
If you need the library inside `setup_file` or `teardown_file` you need to load it in `setup_file`.
|
||||
|
||||
How to set a test timeout in bats?
|
||||
----------------------------------
|
||||
|
||||
Set the variable `$BATS_TEST_TIMEOUT` before `setup()` starts. This means you can set it either on the command line,
|
||||
in free code in the test file or in `setup_file()`.
|
||||
|
||||
How can I lint/shell-format my bats tests?
|
||||
------------------------------------------
|
||||
|
||||
Due to their custom syntax (`@test`), `.bats` files are not standard bash. This prevents most tools from working with bats.
|
||||
However, there is an alternative syntax `function_name { # @test` to declare tests in a bash compliant manner.
|
||||
|
||||
- shellcheck support since version 0.7
|
||||
- shfmt support since version 3.2.0 (using `-ln bats`)
|
||||
|
||||
|
||||
How can I check if a test failed/succeeded during teardown?
|
||||
-----------------------------------------------------------
|
||||
|
||||
You can check `BATS_TEST_COMPLETED` which will be set to 1 if the test was successful or empty if it was not.
|
||||
There is also `BATS_TEST_SKIPPED` which will be non-empty (contains the skip message or -1) when `skip` was called.
|
||||
|
||||
How can I setup/cleanup before/after all tests?
|
||||
-----------------------------------------------
|
||||
|
||||
Setup/cleanup before/after all tests can be achieved using the special `setup_suite` and `teardown_suite` functions.
|
||||
These functions must be placed into a dedicated `setup_suite.bash` file next to your `.bats` files.
|
||||
For more information check out the :ref:`setup and teardown section <setup and teardown: pre- and post-test hooks>`.
|
||||
@@ -0,0 +1,132 @@
|
||||
Gotchas
|
||||
=======
|
||||
|
||||
My test fails although I return true?
|
||||
-------------------------------------
|
||||
|
||||
Using `return 1` to signify `true` for a success as is done often in other languages does not mesh well with Bash's
|
||||
convention of using return code 0 to signify success and everything non-zero to indicate a failure.
|
||||
|
||||
Please adhere to this idiom while using bats, or you will constantly work against your environment.
|
||||
|
||||
My negated statement (e.g. ! true) does not fail the test, even when it should.
|
||||
-------------------------------------------------------------------------------
|
||||
|
||||
Bash deliberately excludes negated return values from causing a pipeline to exit (see bash's `-e` option).
|
||||
Use `run !` on Bats 1.5.0 and above. For older bats versions, use one of `! x || false` or `run` with `[ $status != 0 ]`.
|
||||
|
||||
If the negated command is the final statement in a test, that final statement's (negated) exit status will propagate through to the test's return code as usual.
|
||||
Negated statements of one of the correct forms mentioned above will explicitly fail the test when the pipeline returns true, regardless of where they occur in the test.
|
||||
|
||||
I cannot register a test multiple times via for loop.
|
||||
-----------------------------------------------------
|
||||
|
||||
The usual bats tests (`@test`) are preprocessed into functions.
|
||||
Wrapping them into a for loop only redeclares this function.
|
||||
|
||||
If you are interested in registering multiple calls to the same function, contribute your wishes to issue `#306 <https://github.com/bats-core/bats-core/issues/306>`_.
|
||||
|
||||
I cannot pass parameters to test or .bats files.
|
||||
------------------------------------------------
|
||||
|
||||
Especially while using bats via shebang:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
#!/usr/bin/env bats
|
||||
|
||||
@test "test" {
|
||||
# ...
|
||||
}
|
||||
|
||||
You could be tempted to pass parameters to the test invocation like `./test.bats param1 param2`.
|
||||
However, bats does not support passing parameters to files or tests.
|
||||
If you need such a feature, please let us know about your usecase.
|
||||
|
||||
As a workaround you can use environment variables to pass parameters.
|
||||
|
||||
Why can't my function return results via a variable when using `run`?
|
||||
---------------------------------------------------------------------
|
||||
|
||||
The `run` function executes its command in a subshell which means the changes to variables won't be available in the calling shell.
|
||||
|
||||
If you want to test these functions, you should call them without `run`.
|
||||
|
||||
`run` doesn't fail, although the same command without `run` does.
|
||||
-----------------------------------------------------------------
|
||||
|
||||
`run` is a wrapper that always succeeds. The wrapped command's exit code is stored in `$status` and the stdout/stderr in `$output`.
|
||||
If you want to fail the test, you should explicitly check `$status` or omit `run`. See also `when not to use run <writing-tests.html#when-not-to-use-run>`_.
|
||||
|
||||
`load` won't load my `.sh` files.
|
||||
---------------------------------
|
||||
|
||||
`load` is intended as an internal helper function that always loads `.bash` files (by appending this suffix).
|
||||
If you want to load an `.sh` file, you can simple `source` it.
|
||||
|
||||
I can't lint/shell-format my bats tests.
|
||||
----------------------------------------
|
||||
|
||||
Bats uses a custom syntax for annotating tests (`@test`) that is not bash compliant.
|
||||
Therefore, standard bash tooling won't be able to interact directly with `.bats` files.
|
||||
Shellcheck supports bats' native syntax as of version 0.7.
|
||||
|
||||
Additionally, there is bash compatible syntax for tests:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
function bash_compliant_function_name_as_test_name { # @test
|
||||
# your code
|
||||
}
|
||||
|
||||
|
||||
The output (stdout/err) from commands under `run` is not visible in failed tests.
|
||||
---------------------------------------------------------------------------------
|
||||
|
||||
By default, `run` only stores stdout/stderr in `$output` (and `${lines[@]}`).
|
||||
If you want to see this output, you either should use bat-assert's assertions or have to print `$output` before the check that fails.
|
||||
|
||||
My piped command does not work under run.
|
||||
-----------------------------------------
|
||||
|
||||
Be careful with using pipes and with `run`. While your mind model of `run` might wrap the whole command behind it, bash's parser won't
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
run echo foo | grep bar
|
||||
|
||||
Won't `run (echo foo | grep bar)` but will `(run echo foo) | grep bar`. If you need to incorporate pipes, you either should do
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
run bash -c 'echo foo | grep bar'
|
||||
|
||||
or use a function to wrap the pipe in:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
fun_with_pipes() {
|
||||
echo foo | grep bar
|
||||
}
|
||||
|
||||
run fun_with_pipes
|
||||
|
||||
`[[ ]]` (or `(( ))` did not fail my test
|
||||
----------------------------------------
|
||||
|
||||
The `set -e` handling of `[[ ]]` and `(( ))` changed in Bash 4.1. Older versions, like 3.2 on MacOS,
|
||||
don't abort the test when they fail, unless they are the last command before the (test) function returns,
|
||||
making their exit code the return code.
|
||||
|
||||
`[ ]` does not suffer from this, but is no replacement for all `[[ ]]` usecases. Appending ` || false` will work in all cases.
|
||||
|
||||
Background tasks prevent the test run from terminating when finished
|
||||
--------------------------------------------------------------------
|
||||
|
||||
When running a task in background, it will inherit the opened FDs of the process it was forked from.
|
||||
This means that the background task forked from a Bats test will hold the FD for the pipe to the formatter that prints to the terminal,
|
||||
thus keeping it open until the background task finished.
|
||||
Due to implementation internals of Bats and bash, this pipe might be held in multiple FDs which all have to be closed by the background task.
|
||||
|
||||
You can use `close_non_std_fds from `test/fixtures/bats/issue-205.bats` in the background job to close all FDs except stdin, stdout and stderr, thus solving the problem.
|
||||
More details about the issue can be found in [#205](https://github.com/bats-core/bats-core/issues/205#issuecomment-973572596).
|
||||
@@ -0,0 +1,18 @@
|
||||
Welcome to bats-core's documentation!
|
||||
=====================================
|
||||
|
||||
Versions before v1.2.1 are documented over `there <https://github.com/bats-core/bats-core/blob/master/docs/versions.md>`_.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:caption: Contents:
|
||||
|
||||
tutorial
|
||||
installation
|
||||
usage
|
||||
docker-usage
|
||||
writing-tests
|
||||
gotchas
|
||||
faq
|
||||
warnings/index
|
||||
support-matrix
|
||||
@@ -0,0 +1,138 @@
|
||||
|
||||
Installation
|
||||
============
|
||||
|
||||
Linux: Distribition Package Manager
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Following Linux distributions provide Bats via their package manager:
|
||||
|
||||
* Arch Linux: `extra/bats <https://archlinux.org/packages/extra/any/bats/>`__
|
||||
* Alpine Linux: `bats <https://pkgs.alpinelinux.org/package/edge/main/x86/bats>`__
|
||||
* Debian Linux: `shells/bats <https://packages.debian.org/search?keywords=bats>`__
|
||||
* Fedora Linux: `rpms/bats <https://src.fedoraproject.org/rpms/bats>`__
|
||||
* Gentoo Linux `dev-util/bats <https://packages.gentoo.org/packages/dev-util/bats>`__
|
||||
* OpenSUSE Linux: `bats <https://software.opensuse.org/package/bats>`__
|
||||
* Ubuntu Linux `shells/bats <https://packages.ubuntu.com/search?keywords=bats>`__
|
||||
|
||||
**Note**: Bats versions pre 1.0 are from sstephenson's original project.
|
||||
Consider using one of the other installation methods below to get the latest Bats release.
|
||||
The test matrix above only applies to the latest Bats version.
|
||||
|
||||
If your favorite distribution is not listed above,
|
||||
you can try one of the following package managers or install from source.
|
||||
|
||||
MacOS: Homebrew
|
||||
^^^^^^^^^^^^^^^
|
||||
|
||||
On macOS, you can install `Homebrew <https://brew.sh/>`__ if you haven't already,
|
||||
then run:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ brew install bats-core
|
||||
|
||||
Any OS: npm
|
||||
^^^^^^^^^^^
|
||||
|
||||
You can install the `Bats npm package <https://www.npmjs.com/package/bats>`__ via:
|
||||
|
||||
.. code-block::
|
||||
|
||||
# To install globally:
|
||||
$ npm install -g bats
|
||||
|
||||
# To install into your project and save it as one of the "devDependencies" in
|
||||
# your package.json:
|
||||
$ npm install --save-dev bats
|
||||
|
||||
Any OS: Installing Bats from source
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Check out a copy of the Bats repository. Then, either add the Bats ``bin``
|
||||
directory to your ``$PATH``\ , or run the provided ``install.sh`` command with the
|
||||
location to the prefix in which you want to install Bats. For example, to
|
||||
install Bats into ``/usr/local``\ ,
|
||||
|
||||
.. code-block::
|
||||
|
||||
$ git clone https://github.com/bats-core/bats-core.git
|
||||
$ cd bats-core
|
||||
$ ./install.sh /usr/local
|
||||
|
||||
|
||||
**Note:** You may need to run ``install.sh`` with ``sudo`` if you do not have
|
||||
permission to write to the installation prefix.
|
||||
|
||||
Windows: Installing Bats from source via Git Bash
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Check out a copy of the Bats repository and install it to ``$HOME``. This
|
||||
will place the ``bats`` executable in ``$HOME/bin``\ , which should already be
|
||||
in ``$PATH``.
|
||||
|
||||
.. code-block::
|
||||
|
||||
$ git clone https://github.com/bats-core/bats-core.git
|
||||
$ cd bats-core
|
||||
$ ./install.sh $HOME
|
||||
|
||||
|
||||
Running Bats in Docker
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
There is an official image on the Docker Hub:
|
||||
|
||||
.. code-block::
|
||||
|
||||
$ docker run -it bats/bats:latest --version
|
||||
|
||||
|
||||
Building a Docker image
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Check out a copy of the Bats repository, then build a container image:
|
||||
|
||||
.. code-block::
|
||||
|
||||
$ git clone https://github.com/bats-core/bats-core.git
|
||||
$ cd bats-core
|
||||
$ docker build --tag bats/bats:latest .
|
||||
|
||||
|
||||
This creates a local Docker image called ``bats/bats:latest`` based on `Alpine
|
||||
Linux <https://github.com/gliderlabs/docker-alpine/blob/master/docs/usage.md>`__
|
||||
(to push to private registries, tag it with another organisation, e.g.
|
||||
``my-org/bats:latest``\ ).
|
||||
|
||||
To run Bats' internal test suite (which is in the container image at
|
||||
``/opt/bats/test``\ ):
|
||||
|
||||
.. code-block::
|
||||
|
||||
$ docker run -it bats/bats:latest /opt/bats/test
|
||||
|
||||
|
||||
To run a test suite from a directory called ``test`` in the current directory of
|
||||
your local machine, mount in a volume and direct Bats to its path inside the
|
||||
container:
|
||||
|
||||
.. code-block::
|
||||
|
||||
$ docker run -it -v "${PWD}:/code" bats/bats:latest test
|
||||
|
||||
|
||||
..
|
||||
|
||||
``/code`` is the working directory of the Docker image. "${PWD}/test" is the
|
||||
location of the test directory on the local machine.
|
||||
|
||||
|
||||
This is a minimal Docker image. If more tools are required this can be used as a
|
||||
base image in a Dockerfile using ``FROM <Docker image>``. In the future there may
|
||||
be images based on Debian, and/or with more tools installed (\ ``curl`` and ``openssl``\ ,
|
||||
for example). If you require a specific configuration please search and +1 an
|
||||
issue or `raise a new issue <https://github.com/bats-core/bats-core/issues>`__.
|
||||
|
||||
Further usage examples are in
|
||||
`the wiki <https://github.com/bats-core/bats-core/wiki/Docker-Usage-Examples>`__.
|
||||
@@ -0,0 +1,2 @@
|
||||
sphinxcontrib-programoutput
|
||||
recommonmark
|
||||
@@ -0,0 +1,26 @@
|
||||
Support Matrix
|
||||
==============
|
||||
|
||||
Supported Bash versions
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The following is a list of Bash versions that are currently supported by Bats and verified through automated tests:
|
||||
|
||||
* 3.2.57(1) (macOS's highest bundled version)
|
||||
* 4.0, 4.1, 4.2, 4.3, 4.4
|
||||
* 5.0, 5.1, 5.2
|
||||
|
||||
Supported Operating systems
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The following Operating Systems are supported and tested automatically (CI) or manually during development:
|
||||
|
||||
* Linux: Alpine (CI), Alma 8 (CI), Arch Linux (manual), Ubuntu 20.04/22.04 (CI)
|
||||
* FreeBSD: 11 (CI)
|
||||
* macOS: 11 (CI), 12 (CI)
|
||||
* Windows: Server 2019 (CI), 10 (manual)
|
||||
|
||||
* Git for Windows Bash (MSYS2 based)
|
||||
* Windows Subsystem for Linux
|
||||
* MSYS2
|
||||
* Cygwin
|
||||
@@ -0,0 +1,661 @@
|
||||
Tutorial
|
||||
========
|
||||
|
||||
This tutorial is intended for beginners with bats and possibly bash.
|
||||
Make sure to also read the list of gotchas and the faq.
|
||||
|
||||
For this tutorial we are assuming you already have a project in a git repository and want to add tests.
|
||||
Ultimately they should run in the CI environment but will also be started locally during development.
|
||||
|
||||
..
|
||||
TODO: link to example repository?
|
||||
|
||||
Quick installation
|
||||
------------------
|
||||
|
||||
Since we already have an existing git repository, it is very easy to include bats and its libraries as submodules.
|
||||
We are aiming for following filesystem structure:
|
||||
|
||||
.. code-block::
|
||||
|
||||
src/
|
||||
project.sh
|
||||
...
|
||||
test/
|
||||
bats/ <- submodule
|
||||
test_helper/
|
||||
bats-support/ <- submodule
|
||||
bats-assert/ <- submodule
|
||||
test.bats
|
||||
...
|
||||
|
||||
So we start from the project root:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
git submodule add https://github.com/bats-core/bats-core.git test/bats
|
||||
git submodule add https://github.com/bats-core/bats-support.git test/test_helper/bats-support
|
||||
git submodule add https://github.com/bats-core/bats-assert.git test/test_helper/bats-assert
|
||||
|
||||
Your first test
|
||||
---------------
|
||||
|
||||
Now we want to add our first test.
|
||||
|
||||
In the tutorial repository, we want to build up our project in a TDD fashion.
|
||||
Thus, we start with an empty project and our first test is to just run our (nonexistent) shell script.
|
||||
|
||||
We start by creating a new test file `test/test.bats`
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@test "can run our script" {
|
||||
./project.sh
|
||||
}
|
||||
|
||||
and run it by
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ ./test/bats/bin/bats test/test.bats
|
||||
✗ can run our script
|
||||
(in test file test/test.bats, line 2)
|
||||
`./project.sh' failed with status 127
|
||||
/tmp/bats-run-19605/bats.19627.src: line 2: ./project.sh: No such file or directory
|
||||
|
||||
1 test, 1 failure
|
||||
|
||||
Okay, our test is red. Obviously, the project.sh doesn't exist, so we create the file `src/project.sh`:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
mkdir src/
|
||||
echo '#!/usr/bin/env bash' > src/project.sh
|
||||
chmod a+x src/project.sh
|
||||
|
||||
A new test run gives us
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ ./test/bats/bin/bats test/test.bats
|
||||
✗ can run our script
|
||||
(in test file test/test.bats, line 2)
|
||||
`./project.sh' failed with status 127
|
||||
/tmp/bats-run-19605/bats.19627.src: line 2: ./project.sh: No such file or directory
|
||||
|
||||
1 test, 1 failure
|
||||
|
||||
Oh, we still used the wrong path. No problem, we just need to use the correct path to `project.sh`.
|
||||
Since we're still in the same directory as when we started `bats`, we can simply do:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@test "can run our script" {
|
||||
./src/project.sh
|
||||
}
|
||||
|
||||
and get:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ ./test/bats/bin/bats test/test.bats
|
||||
✓ can run our script
|
||||
|
||||
1 test, 0 failures
|
||||
|
||||
Yesss! But that victory feels shallow: What if somebody less competent than us starts bats from another directory?
|
||||
|
||||
Let's do some setup
|
||||
-------------------
|
||||
|
||||
The obvious solution to becoming independent of `$PWD` is using some fixed anchor point in the filesystem.
|
||||
We can use the path to the test file itself as an anchor and rely on the internal project structure.
|
||||
Since we are lazy people and want to treat our project's files as first class citizens in the executable world, we will also put them on the `$PATH`.
|
||||
Our new `test/test.bats` now looks like this:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
setup() {
|
||||
# get the containing directory of this file
|
||||
# use $BATS_TEST_FILENAME instead of ${BASH_SOURCE[0]} or $0,
|
||||
# as those will point to the bats executable's location or the preprocessed file respectively
|
||||
DIR="$( cd "$( dirname "$BATS_TEST_FILENAME" )" >/dev/null 2>&1 && pwd )"
|
||||
# make executables in src/ visible to PATH
|
||||
PATH="$DIR/../src:$PATH"
|
||||
}
|
||||
|
||||
@test "can run our script" {
|
||||
# notice the missing ./
|
||||
# As we added src/ to $PATH, we can omit the relative path to `src/project.sh`.
|
||||
project.sh
|
||||
}
|
||||
|
||||
still giving us:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ ./test/bats/bin/bats test/test.bats
|
||||
✓ can run our script
|
||||
|
||||
1 test, 0 failures
|
||||
|
||||
It still works as expected. This is because the newly added `setup` function put the absolute path to `src/` onto `$PATH`.
|
||||
This setup function is automatically called before each test.
|
||||
Therefore, our test could execute `project.sh` directly, without using a (relative) path.
|
||||
|
||||
.. important::
|
||||
|
||||
The `setup` function will be called before each individual test in the file.
|
||||
Each file can only define one setup function for all tests in the file.
|
||||
However, the setup functions can differ between different files.
|
||||
|
||||
Dealing with output
|
||||
-------------------
|
||||
|
||||
Okay, we have a green test but our executable does not do anything useful.
|
||||
To keep things simple, let us start with an error message. Our new `src/project.sh` now reads:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
#!/usr/bin/env bash
|
||||
|
||||
echo "Welcome to our project!"
|
||||
|
||||
echo "NOT IMPLEMENTED!" >&2
|
||||
exit 1
|
||||
|
||||
And gives is this test output:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ ./test/bats/bin/bats test/test.bats
|
||||
✗ can run our script
|
||||
(in test file test/test.bats, line 11)
|
||||
`project.sh' failed
|
||||
Welcome to our project!
|
||||
NOT IMPLEMENTED!
|
||||
|
||||
1 test, 1 failure
|
||||
|
||||
Okay, our test failed, because we now exit with 1 instead of 0.
|
||||
Additionally, we see the stdout and stderr of the failing program.
|
||||
|
||||
Our goal now is to retarget our test and check that we get the welcome message.
|
||||
bats-assert gives us some help with this, so we should now load it (and its dependency bats-support),
|
||||
so we change `test/test.bats` to
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
setup() {
|
||||
load 'test_helper/bats-support/load'
|
||||
load 'test_helper/bats-assert/load'
|
||||
# ... the remaining setup is unchanged
|
||||
|
||||
# get the containing directory of this file
|
||||
# use $BATS_TEST_FILENAME instead of ${BASH_SOURCE[0]} or $0,
|
||||
# as those will point to the bats executable's location or the preprocessed file respectively
|
||||
DIR="$( cd "$( dirname "$BATS_TEST_FILENAME" )" >/dev/null 2>&1 && pwd )"
|
||||
# make executables in src/ visible to PATH
|
||||
PATH="$DIR/../src:$PATH"
|
||||
}
|
||||
|
||||
@test "can run our script" {
|
||||
run project.sh # notice `run`!
|
||||
assert_output 'Welcome to our project!'
|
||||
}
|
||||
|
||||
which gives us the following test output:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ LANG=C ./test/bats/bin/bats test/test.bats
|
||||
✗ can run our script
|
||||
(from function `assert_output' in file test/test_helper/bats-assert/src/assert_output.bash, line 194,
|
||||
in test file test/test.bats, line 14)
|
||||
`assert_output 'Welcome to our project!'' failed
|
||||
|
||||
-- output differs --
|
||||
expected (1 lines):
|
||||
Welcome to our project!
|
||||
actual (2 lines):
|
||||
Welcome to our project!
|
||||
NOT IMPLEMENTED!
|
||||
--
|
||||
|
||||
|
||||
1 test, 1 failure
|
||||
|
||||
The first change in this output is the failure description. We now fail on assert_output instead of the call itself.
|
||||
We prefixed our call to `project.sh` with `run`, which is a function provided by bats that executes the command it gets passed as parameters.
|
||||
Then, `run` sucks up the stdout and stderr of the command it ran and stores it in `$output`, stores the exit code in `$status` and returns 0.
|
||||
This means `run` never fails the test and won't generate any context/output in the log of a failed test on its own.
|
||||
|
||||
Marking the test as failed and printing context information is up to the consumers of `$status` and `$output`.
|
||||
`assert_output` is such a consumer, it compares `$output` to the parameter it got and tells us quite succinctly that it did not match in this case.
|
||||
|
||||
For our current test we don't care about any other output or the error message, so we want it gone.
|
||||
`grep` is always at our fingertips, so we tape together this ramshackle construct
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
run project.sh 2>&1 | grep Welcome
|
||||
|
||||
which gives us the following test result:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ ./test/bats/bin/bats test/test.bats
|
||||
✗ can run our script
|
||||
(in test file test/test.bats, line 13)
|
||||
`run project.sh | grep Welcome' failed
|
||||
|
||||
1 test, 1 failure
|
||||
|
||||
Huh, what is going on? Why does it fail the `run` line again?
|
||||
|
||||
This is a common mistake that can happen when our mind parses the file differently than the bash parser.
|
||||
`run` is just a function, so the pipe won't actually be forwarded into the function. Bash reads this as `(run project.sh) | grep Welcome`,
|
||||
instead of our intended `run (project.sh | grep Welcome)`.
|
||||
|
||||
Unfortunately, the latter is not valid bash syntax, so we have to work around it, e.g. by using a function:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
get_projectsh_welcome_message() {
|
||||
project.sh 2>&1 | grep Welcome
|
||||
}
|
||||
|
||||
@test "Check welcome message" {
|
||||
run get_projectsh_welcome_message
|
||||
assert_output 'Welcome to our project!'
|
||||
}
|
||||
|
||||
Now our test passes again but having to write a function each time we want only a partial match does not accommodate our laziness.
|
||||
Isn't there an app for that? Maybe we should look at the documentation?
|
||||
|
||||
Partial matching can be enabled with the --partial option (-p for short). When used, the assertion fails if the expected substring is not found in $output.
|
||||
|
||||
-- the documentation for `assert_output <https://github.com/bats-core/bats-assert#partial-matching>`_
|
||||
|
||||
Okay, so maybe we should try that:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@test "Check welcome message" {
|
||||
run project.sh
|
||||
assert_output --partial 'Welcome to our project!'
|
||||
}
|
||||
|
||||
Aaannnd ... the test stays green. Yay!
|
||||
|
||||
There are many other asserts and options but this is not the place for all of them.
|
||||
Skimming the documentation of `bats-assert <https://github.com/bats-core/bats-assert>`_ will give you a good idea what you can do.
|
||||
You should also have a look at the other helper libraries `here <https://github.com/bats-core>`_ like `bats-file <https://github.com/bats-core/bats-file>`_,
|
||||
to avoid reinventing the wheel.
|
||||
|
||||
|
||||
Cleaning up your mess
|
||||
---------------------
|
||||
|
||||
Often our setup or tests leave behind some artifacts that clutter our test environment.
|
||||
You can define a `teardown` function which will be called after each test, regardless whether it failed or not.
|
||||
|
||||
For example, we now want our project.sh to only show the welcome message on the first invocation.
|
||||
So we change our test to this:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@test "Show welcome message on first invocation" {
|
||||
run project.sh
|
||||
assert_output --partial 'Welcome to our project!'
|
||||
|
||||
run project.sh
|
||||
refute_output --partial 'Welcome to our project!'
|
||||
}
|
||||
|
||||
This test fails as expected:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ ./test/bats/bin/bats test/test.bats
|
||||
✗ Show welcome message on first invocation
|
||||
(from function `refute_output' in file test/test_helper/bats-assert/src/refute_output.bash, line 189,
|
||||
in test file test/test.bats, line 17)
|
||||
`refute_output --partial 'Welcome to our project!'' failed
|
||||
|
||||
-- output should not contain substring --
|
||||
substring (1 lines):
|
||||
Welcome to our project!
|
||||
output (2 lines):
|
||||
Welcome to our project!
|
||||
NOT IMPLEMENTED!
|
||||
--
|
||||
|
||||
|
||||
1 test, 1 failure
|
||||
|
||||
Now, to get the test green again, we want to store the information that we already ran in the file `/tmp/bats-tutorial-project-ran`,
|
||||
so our `src/project.sh` becomes:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
#!/usr/bin/env bash
|
||||
|
||||
FIRST_RUN_FILE=/tmp/bats-tutorial-project-ran
|
||||
|
||||
if [[ ! -e "$FIRST_RUN_FILE" ]]; then
|
||||
echo "Welcome to our project!"
|
||||
touch "$FIRST_RUN_FILE"
|
||||
fi
|
||||
|
||||
echo "NOT IMPLEMENTED!" >&2
|
||||
exit 1
|
||||
|
||||
And our test says:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ ./test/bats/bin/bats test/test.bats
|
||||
✓ Show welcome message on first invocation
|
||||
|
||||
1 test, 0 failures
|
||||
|
||||
Nice, we're done, or are we? Running the test again now gives:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ ./test/bats/bin/bats test/test.bats
|
||||
✗ Show welcome message on first invocation
|
||||
(from function `assert_output' in file test/test_helper/bats-assert/src/assert_output.bash, line 186,
|
||||
in test file test/test.bats, line 14)
|
||||
`assert_output --partial 'Welcome to our project!'' failed
|
||||
|
||||
-- output does not contain substring --
|
||||
substring : Welcome to our project!
|
||||
output : NOT IMPLEMENTED!
|
||||
--
|
||||
|
||||
|
||||
1 test, 1 failure
|
||||
|
||||
Now the first assert failed, because of the leftover `$FIRST_RUN_FILE` from the last test run.
|
||||
|
||||
Luckily, bats offers the `teardown` function, which can take care of that, we add the following code to `test/test.bats`:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
teardown() {
|
||||
rm -f /tmp/bats-tutorial-project-ran
|
||||
}
|
||||
|
||||
Now running the test again first give us the same error, as the teardown has not run yet.
|
||||
On the second try we get a clean `/tmp` folder again and our test passes consistently now.
|
||||
|
||||
It is worth noting that we could do this `rm` in the test code itself but it would get skipped on failures.
|
||||
|
||||
.. important::
|
||||
|
||||
A test ends at its first failure. None of the subsequent commands in this test will be executed.
|
||||
The `teardown` function runs after each individual test in a file, regardless of test success or failure.
|
||||
Similarly to `setup`, each `.bats` file can have its own `teardown` function which will be the same for all tests in the file.
|
||||
|
||||
Test what you can
|
||||
-----------------
|
||||
|
||||
Sometimes tests rely on the environment to provide infrastructure that is needed for the test.
|
||||
If not all test environments provide this infrastructure but we still want to test on them,
|
||||
it would be unhelpful to get errors on parts that are not testable.
|
||||
|
||||
Bats provides you with the `skip` command which can be used in `setup` and `test`.
|
||||
|
||||
.. tip::
|
||||
|
||||
You should `skip` as early as you know it does not make sense to continue.
|
||||
|
||||
In our example project we rewrite the welcome message test to `skip` instead of doing cleanup:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
teardown() {
|
||||
: # Look Ma! No cleanup!
|
||||
}
|
||||
|
||||
@test "Show welcome message on first invocation" {
|
||||
if [[ -e /tmp/bats-tutorial-project-ran ]]; then
|
||||
skip 'The FIRST_RUN_FILE already exists'
|
||||
fi
|
||||
|
||||
run project.sh
|
||||
assert_output --partial 'Welcome to our project!'
|
||||
|
||||
run project.sh
|
||||
refute_output --partial 'Welcome to our project!'
|
||||
}
|
||||
|
||||
The first test run still works due to the cleanup from the last round. However, our second run gives us:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ ./test/bats/bin/bats test/test.bats
|
||||
- Show welcome message on first invocation (skipped: The FIRST_RUN_FILE already exists)
|
||||
|
||||
1 test, 0 failures, 1 skipped
|
||||
|
||||
.. important::
|
||||
|
||||
Skipped tests won't fail a test suite and are counted separately.
|
||||
No test command after `skip` will be executed. If an error occurs before `skip`, the test will fail.
|
||||
An optional reason can be passed to `skip` and will be printed in the test output.
|
||||
|
||||
Setting up a multifile test suite
|
||||
---------------------------------
|
||||
|
||||
With a growing project, putting all tests into one file becomes unwieldy.
|
||||
For our example project, we will extract functionality into the additional file `src/helper.sh`:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
#!/usr/bin/env bash
|
||||
|
||||
_is_first_run() {
|
||||
local FIRST_RUN_FILE=/tmp/bats-tutorial-project-ran
|
||||
if [[ ! -e "$FIRST_RUN_FILE" ]]; then
|
||||
touch "$FIRST_RUN_FILE"
|
||||
return 0
|
||||
fi
|
||||
return 1
|
||||
}
|
||||
|
||||
This allows for testing it separately in a new file `test/helper.bats`:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
setup() {
|
||||
load 'test_helper/common-setup'
|
||||
_common_setup
|
||||
|
||||
source "$PROJECT_ROOT/src/helper.sh"
|
||||
}
|
||||
|
||||
teardown() {
|
||||
rm -f "$NON_EXISTANT_FIRST_RUN_FILE"
|
||||
rm -f "$EXISTING_FIRST_RUN_FILE"
|
||||
}
|
||||
|
||||
@test "Check first run" {
|
||||
NON_EXISTANT_FIRST_RUN_FILE=$(mktemp -u) # only create the name, not the file itself
|
||||
|
||||
assert _is_first_run
|
||||
refute _is_first_run
|
||||
refute _is_first_run
|
||||
|
||||
EXISTING_FIRST_RUN_FILE=$(mktemp)
|
||||
refute _is_first_run
|
||||
refute _is_first_run
|
||||
}
|
||||
|
||||
Since the setup function would have duplicated much of the other files', we split that out into the file `test/test_helper/common-setup.bash`:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
#!/usr/bin/env bash
|
||||
|
||||
_common_setup() {
|
||||
load 'test_helper/bats-support/load'
|
||||
load 'test_helper/bats-assert/load'
|
||||
# get the containing directory of this file
|
||||
# use $BATS_TEST_FILENAME instead of ${BASH_SOURCE[0]} or $0,
|
||||
# as those will point to the bats executable's location or the preprocessed file respectively
|
||||
PROJECT_ROOT="$( cd "$( dirname "$BATS_TEST_FILENAME" )/.." >/dev/null 2>&1 && pwd )"
|
||||
# make executables in src/ visible to PATH
|
||||
PATH="$PROJECT_ROOT/src:$PATH"
|
||||
}
|
||||
|
||||
with the following `setup` in `test/test.bats`:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
setup() {
|
||||
load 'test_helper/common-setup'
|
||||
_common_setup
|
||||
}
|
||||
|
||||
Please note, that we gave our helper the extension `.bash`, which is automatically appended by `load`.
|
||||
|
||||
.. important::
|
||||
|
||||
`load` automatically tries to append `.bash` to its argument.
|
||||
|
||||
In our new `test/helper.bats` we can see, that loading `.sh` is simply done via `source`.
|
||||
|
||||
.. tip::
|
||||
|
||||
Avoid using `load` and `source` outside of any functions.
|
||||
If there is an error in the test file's "free code", the diagnostics are much worse than for code in `setup` or `@test`.
|
||||
|
||||
With the new changes in place, we can run our tests again. However, our previous run command does not include the new file.
|
||||
You could add the new file to the parameter list, e.g. by running `./test/bats/bin/bats test/*.bats`.
|
||||
However, bats also can handle directories:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ ./test/bats/bin/bats test/
|
||||
✓ Check first run
|
||||
- Show welcome message on first invocation (skipped: The FIRST_RUN_FILE already exists)
|
||||
|
||||
2 tests, 0 failures, 1 skipped
|
||||
|
||||
In this mode, bats will pick up all `.bats` files in the directory it was given. There is an additional `-r` switch that will recursively search for more `.bats` files.
|
||||
However, in our project layout this would pick up the test files of bats itself from `test/bats/test`. We don't have test subfolders anyways, so we can do without `-r`.
|
||||
|
||||
|
||||
Avoiding costly repeated setups
|
||||
-------------------------------
|
||||
|
||||
We already have seen the `setup` function in use, which is called before each test.
|
||||
Sometimes our setup is very costly, such as booting up a service just for testing.
|
||||
If we can reuse the same setup across multiple tests, we might want to do only one setup before all these tests.
|
||||
|
||||
This usecase is exactly what the `setup_file` function was created for.
|
||||
It can be defined per file and will run before all tests of the respective file.
|
||||
Similarly, we have `teardown_file`, which will run after all tests of the file, even when you abort a test run or a test failed.
|
||||
|
||||
As an example, we want to add an echo server capability to our project. First, we add the following `server.bats` to our suite:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
setup_file() {
|
||||
load 'test_helper/common-setup'
|
||||
_common_setup
|
||||
PORT=$(project.sh start-echo-server 2>&1 >/dev/null)
|
||||
export PORT
|
||||
}
|
||||
|
||||
@test "server is reachable" {
|
||||
nc -z localhost "$PORT"
|
||||
}
|
||||
|
||||
Which will obviously fail:
|
||||
|
||||
Note that `export PORT` to make it visible to the test!
|
||||
Running this gives us:
|
||||
|
||||
..
|
||||
TODO: Update this example with fixed test name reporting from setup_file? (instead of "✗ ")
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ ./test/bats/bin/bats test/server.bats
|
||||
✗
|
||||
(from function `setup_file' in test file test/server.bats, line 4)
|
||||
`PORT=$(project.sh start-echo-server >/dev/null 2>&1)' failed
|
||||
|
||||
1 test, 1 failure
|
||||
|
||||
Now that we got our red test, we need to get it green again.
|
||||
Our new `project.sh` now ends with:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
case $1 in
|
||||
start-echo-server)
|
||||
echo "Starting echo server"
|
||||
PORT=2000
|
||||
ncat -l $PORT -k -c 'xargs -n1 echo' 2>/dev/null & # don't keep open this script's stderr
|
||||
echo $! > /tmp/project-echo-server.pid
|
||||
echo "$PORT" >&2
|
||||
;;
|
||||
*)
|
||||
echo "NOT IMPLEMENTED!" >&2
|
||||
exit 1
|
||||
;;
|
||||
esac
|
||||
|
||||
and the tests now say
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ LANG=C ./test/bats/bin/bats test/server.bats
|
||||
✓ server is reachable
|
||||
|
||||
1 test, 0 failures
|
||||
|
||||
However, running this a second time gives:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ ./test/bats/bin/bats test/server.bats
|
||||
✗ server is reachable
|
||||
(in test file test/server.bats, line 14)
|
||||
`nc -z -w 2 localhost "$PORT"' failed
|
||||
2000
|
||||
Ncat: bind to :::2000: Address already in use. QUITTING.
|
||||
nc: port number invalid: 2000
|
||||
Ncat: bind to :::2000: Address already in use. QUITTING.
|
||||
|
||||
1 test, 1 failure
|
||||
|
||||
Obviously, we did not turn off our server after testing.
|
||||
This is a task for `teardown_file` in `server.bats`:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
teardown_file() {
|
||||
project.sh stop-echo-server
|
||||
}
|
||||
|
||||
Our `project.sh` should also get the new command:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
stop-echo-server)
|
||||
kill "$(< "/tmp/project-echo-server.pid")"
|
||||
rm /tmp/project-echo-server.pid
|
||||
;;
|
||||
|
||||
Now starting our tests again will overwrite the .pid file with the new instance's, so we have to do manual cleanup once.
|
||||
From now on, our test should clean up after itself.
|
||||
|
||||
.. note::
|
||||
|
||||
`teardown_file` will run regardless of tests failing or succeeding.
|
||||
@@ -0,0 +1,114 @@
|
||||
# Usage
|
||||
|
||||
Bats comes with two manual pages. After installation you can view them with `man
|
||||
1 bats` (usage manual) and `man 7 bats` (writing test files manual). Also, you
|
||||
can view the available command line options that Bats supports by calling Bats
|
||||
with the `-h` or `--help` options. These are the options that Bats currently
|
||||
supports:
|
||||
|
||||
``` eval_rst
|
||||
.. program-output:: ../../bin/bats --help
|
||||
```
|
||||
|
||||
To run your tests, invoke the `bats` interpreter with one or more paths to test
|
||||
files ending with the `.bats` extension, or paths to directories containing test
|
||||
files. (`bats` will only execute `.bats` files at the top level of each
|
||||
directory; it will not recurse unless you specify the `-r` flag.)
|
||||
|
||||
Test cases from each file are run sequentially and in isolation. If all the test
|
||||
cases pass, `bats` exits with a `0` status code. If there are any failures,
|
||||
`bats` exits with a `1` status code.
|
||||
|
||||
When you run Bats from a terminal, you'll see output as each test is performed,
|
||||
with a check-mark next to the test's name if it passes or an "X" if it fails.
|
||||
|
||||
```text
|
||||
$ bats addition.bats
|
||||
✓ addition using bc
|
||||
✓ addition using dc
|
||||
|
||||
2 tests, 0 failures
|
||||
```
|
||||
|
||||
If Bats is not connected to a terminal—in other words, if you run it from a
|
||||
continuous integration system, or redirect its output to a file—the results are
|
||||
displayed in human-readable, machine-parsable [TAP format][tap-format].
|
||||
|
||||
You can force TAP output from a terminal by invoking Bats with the `--formatter tap`
|
||||
option.
|
||||
|
||||
```text
|
||||
$ bats --formatter tap addition.bats
|
||||
1..2
|
||||
ok 1 addition using bc
|
||||
ok 2 addition using dc
|
||||
```
|
||||
|
||||
With `--formatter junit`, it is possible
|
||||
to output junit-compatible report files.
|
||||
|
||||
```text
|
||||
$ bats --formatter junit addition.bats
|
||||
1..2
|
||||
ok 1 addition using bc
|
||||
ok 2 addition using dc
|
||||
```
|
||||
|
||||
If you have your own formatter, you can use an absolute path to the executable
|
||||
to use it:
|
||||
|
||||
```bash
|
||||
$ bats --formatter /absolute/path/to/my-formatter addition.bats
|
||||
addition using bc WORKED
|
||||
addition using dc FAILED
|
||||
```
|
||||
|
||||
You can also generate test report files via `--report-formatter` which accepts
|
||||
the same options as `--formatter`. By default, the file is stored in the current
|
||||
workdir. However, it may be placed elsewhere by specifying the `--output` flag.
|
||||
|
||||
```text
|
||||
$ bats --report-formatter junit addition.bats --output /tmp
|
||||
1..2
|
||||
ok 1 addition using bc
|
||||
ok 2 addition using dc
|
||||
|
||||
$ cat /tmp/report.xml
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<testsuites time="0.073">
|
||||
<testsuite name="addition.bats" tests="2" failures="0" errors="0" skipped="0">
|
||||
<testcase classname="addition.bats" name="addition using bc" time="0.034" />
|
||||
<testcase classname="addition.bats" name="addition using dc" time="0.039" />
|
||||
</testsuite>
|
||||
</testsuites>
|
||||
```
|
||||
|
||||
## Parallel Execution
|
||||
|
||||
``` eval_rst
|
||||
.. versionadded:: 1.0.0
|
||||
```
|
||||
|
||||
By default, Bats will execute your tests serially. However, Bats supports
|
||||
parallel execution of tests (provided you have [GNU parallel][gnu-parallel] or
|
||||
a compatible replacement installed) using the `--jobs` parameter. This can
|
||||
result in your tests completing faster (depending on your tests and the testing
|
||||
hardware).
|
||||
|
||||
Ordering of parallelised tests is not guaranteed, so this mode may break suites
|
||||
with dependencies between tests (or tests that write to shared locations). When
|
||||
enabling `--jobs` for the first time be sure to re-run bats multiple times to
|
||||
identify any inter-test dependencies or non-deterministic test behaviour.
|
||||
|
||||
When parallelizing, the results of a file only become visible after it has been finished.
|
||||
You can use `--no-parallelize-across-files` to get immediate output at the cost of reduced
|
||||
overall parallelity, as parallelization will only happen within files and files will be run
|
||||
sequentially.
|
||||
|
||||
If you have files where tests within the file would interfere with each other, you can use
|
||||
`--no-parallelize-within-files` to disable parallelization within all files.
|
||||
If you want more fine-grained control, you can `export BATS_NO_PARALLELIZE_WITHIN_FILE=true` in `setup_file()`
|
||||
or outside any function to disable parallelization only within the containing file.
|
||||
|
||||
[tap-format]: https://testanything.org
|
||||
[gnu-parallel]: https://www.gnu.org/software/parallel/
|
||||
@@ -0,0 +1,17 @@
|
||||
BW01: `run`'s command `<command>` exited with code 127, indicating 'Command not found'. Use run's return code checks, e.g. `run -127`, to fix this message.
|
||||
===========================================================================================================================================================
|
||||
|
||||
Due to `run`'s default behavior of always succeeding, errors in the command string can remain hidden from the user, e.g.[here](https://github.com/bats-core/bats-core/issues/578).
|
||||
As a proxy for this problem, the return code is checked for value 127 ("Command not found").
|
||||
|
||||
How to fix
|
||||
----------
|
||||
|
||||
If your command should actually return code 127, then you can simply use `run -127 <your command>` to state your intent and the message will go away.
|
||||
|
||||
If your command should not return 127, you should fix the problem with the command.
|
||||
Take a careful look at the command string in the warning message, to see if it contains code that you did not intend to run.
|
||||
|
||||
If your command should sometimes return 127, but never 0, you can use `run ! <your command>`.
|
||||
|
||||
If your command can sometimes return 127 and sometimes 0, the please submit an issue.
|
||||
@@ -0,0 +1,46 @@
|
||||
BW02: <feature> requires at least BATS_VERSION=<version>. Use `bats_require_minimum_version <version>` to fix this message.
|
||||
===========================================================================================================================
|
||||
|
||||
Using a feature that is only available starting with a certain version can be a problem when your tests also run on older versions of Bats.
|
||||
In most cases, running this code in older versions will generate an error due to a missing command.
|
||||
However, in cases like `run`'s where old version simply take all parameters as command to execute, the failure can be silent.
|
||||
|
||||
How to fix BW02
|
||||
---------------
|
||||
|
||||
When you encounter this warning, you can simply guard your code with `bats_require_minimum_version <version>` as the message says.
|
||||
For example, consider the following code:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@test test {
|
||||
bats_require_minimum_version 1.5.0
|
||||
# pre 1.5.0 the flag --separate-stderr would be interpreted as command to run
|
||||
run --separate-stderr some-command
|
||||
[ $output = "blablabla" ]
|
||||
}
|
||||
|
||||
|
||||
The call to `bats_require_minimum_version` can be put anywhere before the warning generating command, even in `setup`, `setup_file`, or even outside any function.
|
||||
This can be used to give fine control over the version dependencies:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@test test {
|
||||
bats_require_minimum_version 1.5.0
|
||||
# pre 1.5.0 the flag --separate-stderr would be interpreted as command to run
|
||||
run --separate-stderr some-command
|
||||
[ $output = "blablabla" ]
|
||||
}
|
||||
|
||||
@test test2 {
|
||||
run some-other-command # no problem executing on earlier version
|
||||
}
|
||||
|
||||
|
||||
If the above code is executed on a system with a `BATS_VERSION` pre 1.5.0, the first test will fail on `bats_require_minimum_version 1.5.0`.
|
||||
|
||||
Instances:
|
||||
----------
|
||||
|
||||
- run's non command parameters like `--keep-empty-lines` are only available since 1.5.0
|
||||
@@ -0,0 +1,15 @@
|
||||
BW03: `setup_suite` is visible to test file '<path>', but was not executed. It belongs into 'setup_suite.bash' to be picked up automatically.
|
||||
=============================================================================================================================================
|
||||
|
||||
In contrast to the other setup functions, `setup_suite` must not be defined in `*.bats` files but in `setup_suite.bash`.
|
||||
When a file is executed and sees `setup_suite` defined but not run before the tests, this warning will be printed.
|
||||
|
||||
How to fix BW03
|
||||
---------------
|
||||
|
||||
The fix depends on your actual intention. There are basically two cases:
|
||||
|
||||
1. You want a setup before all tests and accidentally put `setup_suite` into a test file instead of `setup_suite.bash`.
|
||||
Simply move `setup_suite` (and `teardown_suite`!) into `setup_suite.bash`.
|
||||
2. You did not mean to run a setup before any test but need to defined a function named `setup_suite` in your test file.
|
||||
In this case, you can silence this warning by assigning `BATS_SETUP_SUITE_COMPLETED='suppress BW03'`.
|
||||
@@ -0,0 +1,28 @@
|
||||
Warnings
|
||||
========
|
||||
|
||||
Starting with version 1.7.0 Bats shows warnings about issues it found during the test run.
|
||||
They are printed on stderr after all other output:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
BW01.bats
|
||||
✓ Trigger BW01
|
||||
|
||||
1 test, 0 failures
|
||||
|
||||
|
||||
The following warnings were encountered during tests:
|
||||
BW01: `run`'s command `=0 actually-intended-command with some args` exited with code 127, indicating 'Command not found'. Use run's return code checks, e.g. `run -127`, to fix this message.
|
||||
(from function `run' in file lib/bats-core/test_functions.bash, line 299,
|
||||
in test file test/fixtures/warnings/BW01.bats, line 3)
|
||||
|
||||
A warning will not make a successful run fail but should be investigated and taken seriously, since it hints at a possible error.
|
||||
|
||||
Currently, Bats emits the following warnings:
|
||||
|
||||
.. toctree::
|
||||
|
||||
BW01
|
||||
BW02
|
||||
BW03
|
||||
@@ -0,0 +1,614 @@
|
||||
# Writing tests
|
||||
|
||||
Each Bats test file is evaluated _n+1_ times, where _n_ is the number of
|
||||
test cases in the file. The first run counts the number of test cases,
|
||||
then iterates over the test cases and executes each one in its own
|
||||
process.
|
||||
|
||||
For more details about how Bats evaluates test files, see [Bats Evaluation
|
||||
Process][bats-eval] on the wiki.
|
||||
|
||||
For sample test files, see [examples](https://github.com/bats-core/bats-core/tree/master/docs/examples).
|
||||
|
||||
[bats-eval]: https://github.com/bats-core/bats-core/wiki/Bats-Evaluation-Process
|
||||
|
||||
## Tagging tests
|
||||
|
||||
Starting with version 1.8.0, Bats comes with a tagging system that allows users
|
||||
to categorize their tests and filter according to those categories.
|
||||
|
||||
Each test has a list of tags attached to it. Without specification, this list is empty.
|
||||
Tags can be defined in two ways. The first being `# bats test_tags=`:
|
||||
|
||||
```bash
|
||||
# bats test_tags=tag:1, tag:2, tag:3
|
||||
@test "first test" {
|
||||
# ...
|
||||
}
|
||||
|
||||
@test "second test" {
|
||||
# ...
|
||||
}
|
||||
```
|
||||
|
||||
These tags (`tag:1`, `tag:2`, `tag:3`) will be attached to the test `first test`.
|
||||
The second test will have no tags attached. Values defined in the `# bats test_tags=`
|
||||
directive will be assigned to the next `@test` that is being encountered in the
|
||||
file and forgotten after that. Only the value of the last `# bats test_tags=` directive
|
||||
before a given test will be used.
|
||||
|
||||
Sometimes, we want to give all tests in a file a set of the same tags. This can
|
||||
be achieved via `# bats file_tags=`. They will be added to all tests in the file
|
||||
after that directive. An additional `# bats file_tags=` directive will override
|
||||
the previously defined values:
|
||||
|
||||
```bash
|
||||
@test "Zeroth test" {
|
||||
# will have no tags
|
||||
}
|
||||
|
||||
# bats file_tags=a:b
|
||||
# bats test_tags=c:d
|
||||
|
||||
@test "First test" {
|
||||
# will be tagged a:b, c:d
|
||||
}
|
||||
|
||||
# bats file_tags=
|
||||
|
||||
@test "Second test" {
|
||||
# will have no tags
|
||||
}
|
||||
```
|
||||
|
||||
Tags are case sensitive and must only consist of alphanumeric characters and `_`,
|
||||
`-`, or `:`. They must not contain whitespaces!
|
||||
The colon is intended as a separator for (recursive) namespacing.
|
||||
|
||||
Tag lists must be separated by commas and are allowed to contain whitespace.
|
||||
They must not contain empty tags like `test_tags=,b` (first tag is empty),
|
||||
`test_tags=a,,c`, `test_tags=a, ,c` (second tag is only whitespace/empty),
|
||||
`test_tags=a,b,` (third tag is empty).
|
||||
|
||||
Every tag starting with `bats:` (case insensitive!) is reserved for Bats'
|
||||
internal use.
|
||||
|
||||
### Special tags
|
||||
|
||||
#### Focusing on tests with `bats:focus` tag
|
||||
|
||||
If a test with the tag `bats:focus` is encountered in a test suite,
|
||||
all other tests will be filtered out and only those tagged with this tag will be executed.
|
||||
|
||||
In focus mode, the exit code of successful runs will be overridden to 1 to prevent CI from silently running on a subset of tests due to an accidentally committed `bats:focus` tag.
|
||||
Should you require the true exit code, e.g. for a `git bisect` operation, you can disable this behavior by setting
|
||||
`BATS_NO_FAIL_FOCUS_RUN=1` when running `bats`, but make sure not to commit this to CI!
|
||||
|
||||
### Filtering execution
|
||||
|
||||
Tags can be used for more finegrained filtering of which tests to run via `--filter-tags`.
|
||||
This accepts a comma separated list of tags. Only tests that match all of these
|
||||
tags will be executed. For example, `bats --filter-tags a,b,c` will pick up tests
|
||||
with tags `a,b,c`, but not tests that miss one or more of those tags.
|
||||
|
||||
Additionally, you can specify negative tags via `bats --filter-tags a,!b,c`,
|
||||
which now won't match tests with tags `a,b,c`, due to the `b`, but will select `a,c`.
|
||||
To put it more formally, `--filter-tags` is a boolean conjunction.
|
||||
|
||||
To allow for more complex queries, you can specify multiple `--filter-tags`.
|
||||
A test will be executed, if it matches at least one of them.
|
||||
This means multiple `--filter-tags` form a boolean disjunction.
|
||||
|
||||
A query of `--filter-tags a,!b --filter-tags b,c` can be translated to:
|
||||
Execute only tests that (have tag a, but not tag b) or (have tag b and c).
|
||||
|
||||
An empty tag list matches tests without tags.
|
||||
|
||||
## Comment syntax
|
||||
|
||||
External tools (like `shellcheck`, `shfmt`, and various IDE's) may not support
|
||||
the standard `.bats` syntax. Because of this, we provide a valid `bash`
|
||||
alternative:
|
||||
|
||||
```bash
|
||||
function invoking_foo_without_arguments_prints_usage { #@test
|
||||
run foo
|
||||
[ "$status" -eq 1 ]
|
||||
[ "${lines[0]}" = "usage: foo <filename>" ]
|
||||
}
|
||||
```
|
||||
|
||||
When using this syntax, the function name will be the title in the result output
|
||||
and the value checked when using `--filter`.
|
||||
|
||||
## `run`: Test other commands
|
||||
|
||||
Many Bats tests need to run a command and then make assertions about its exit
|
||||
status and output. Bats includes a `run` helper that invokes its arguments as a
|
||||
command, saves the exit status and output into special global variables, and
|
||||
then returns with a `0` status code so you can continue to make assertions in
|
||||
your test case.
|
||||
|
||||
For example, let's say you're testing that the `foo` command, when passed a
|
||||
nonexistent filename, exits with a `1` status code and prints an error message.
|
||||
|
||||
```bash
|
||||
@test "invoking foo with a nonexistent file prints an error" {
|
||||
run foo nonexistent_filename
|
||||
[ "$status" -eq 1 ]
|
||||
[ "$output" = "foo: no such file 'nonexistent_filename'" ]
|
||||
[ "$BATS_RUN_COMMAND" = "foo nonexistent_filename" ]
|
||||
|
||||
}
|
||||
```
|
||||
|
||||
The `$status` variable contains the status code of the command, the
|
||||
`$output` variable contains the combined contents of the command's standard
|
||||
output and standard error streams, and the `$BATS_RUN_COMMAND` string contains the
|
||||
command and command arguments passed to `run` for execution.
|
||||
|
||||
If invoked with one of the following as the first argument, `run`
|
||||
will perform an implicit check on the exit status of the invoked command:
|
||||
|
||||
```pre
|
||||
-N expect exit status N (0-255), fail if otherwise
|
||||
! expect nonzero exit status (1-255), fail if command succeeds
|
||||
```
|
||||
|
||||
We can then write the above more elegantly as:
|
||||
|
||||
```bash
|
||||
@test "invoking foo with a nonexistent file prints an error" {
|
||||
run -1 foo nonexistent_filename
|
||||
[ "$output" = "foo: no such file 'nonexistent_filename'" ]
|
||||
}
|
||||
```
|
||||
|
||||
A third special variable, the `$lines` array, is available for easily accessing
|
||||
individual lines of output. For example, if you want to test that invoking `foo`
|
||||
without any arguments prints usage information on the first line:
|
||||
|
||||
```bash
|
||||
@test "invoking foo without arguments prints usage" {
|
||||
run -1 foo
|
||||
[ "${lines[0]}" = "usage: foo <filename>" ]
|
||||
}
|
||||
```
|
||||
|
||||
__Note:__ The `run` helper executes its argument(s) in a subshell, so if
|
||||
writing tests against environmental side-effects like a variable's value
|
||||
being changed, these changes will not persist after `run` completes.
|
||||
|
||||
By default `run` leaves out empty lines in `${lines[@]}`. Use
|
||||
`run --keep-empty-lines` to retain them.
|
||||
|
||||
Additionally, you can use `--separate-stderr` to split stdout and stderr
|
||||
into `$output`/`$stderr` and `${lines[@]}`/`${stderr_lines[@]}`.
|
||||
|
||||
All additional parameters to run should come before the command.
|
||||
If you want to run a command that starts with `-`, prefix it with `--` to
|
||||
prevent `run` from parsing it as an option.
|
||||
|
||||
### When not to use `run`
|
||||
|
||||
In case you only need to check the command succeeded, it is better to not use `run`, since the following code
|
||||
|
||||
```bash
|
||||
run -0 command args ...
|
||||
```
|
||||
|
||||
is equivalent to
|
||||
|
||||
```bash
|
||||
command args ...
|
||||
```
|
||||
|
||||
(because bats sets `set -e` for all tests).
|
||||
|
||||
__Note__: In contrast to the above, testing that a command failed is best done via
|
||||
|
||||
```bash
|
||||
run ! command args ...
|
||||
```
|
||||
|
||||
because
|
||||
|
||||
```bash
|
||||
! command args ...
|
||||
```
|
||||
|
||||
will only fail the test if it is the last command and thereby determines the test function's exit code.
|
||||
This is due to Bash's decision to (counterintuitively?) not trigger `set -e` on `!` commands.
|
||||
(See also [the associated gotcha](https://bats-core.readthedocs.io/en/stable/gotchas.html#my-negated-statement-e-g-true-does-not-fail-the-test-even-when-it-should))
|
||||
|
||||
|
||||
### `run` and pipes
|
||||
|
||||
Don't fool yourself with pipes when using `run`. Bash parses the pipe outside of `run`, not internal to its command. Take this example:
|
||||
|
||||
```bash
|
||||
run command args ... | jq -e '.limit == 42'
|
||||
```
|
||||
|
||||
Here, `jq` receives no input (which is captured by `run`),
|
||||
executes no filters, and always succeeds, so the test does not work as
|
||||
expected.
|
||||
|
||||
Instead use a Bash subshell:
|
||||
|
||||
```bash
|
||||
run bash -c "command args ... | jq -e '.limit == 42'"
|
||||
```
|
||||
|
||||
This subshell is a fresh Bash environment, and will only inherit variables
|
||||
and functions that are exported into it.
|
||||
|
||||
```bash
|
||||
limit() { jq -e '.limit == 42'; }
|
||||
export -f limit
|
||||
run bash -c "command args ... | limit"
|
||||
```
|
||||
|
||||
|
||||
## `load`: Share common code
|
||||
|
||||
You may want to share common code across multiple test files. Bats
|
||||
includes a convenient `load` command for sourcing a Bash source files
|
||||
relative to the current test file and from absolute paths.
|
||||
|
||||
For example, if you have a Bats test in `test/foo.bats`, the command
|
||||
|
||||
```bash
|
||||
load test_helper.bash
|
||||
```
|
||||
|
||||
will source the script `test/test_helper.bash` in your test file (limitations
|
||||
apply, see below). This can be useful for sharing functions to set up your
|
||||
environment or load fixtures. `load` delegates to Bash's `source` command after
|
||||
resolving paths.
|
||||
|
||||
If `load` encounters errors - e.g. because the targeted source file
|
||||
errored - it will print a message with the failing library and Bats
|
||||
exits.
|
||||
|
||||
To allow to use `load` in conditions `bats_load_safe` has been added.
|
||||
`bats_load_safe` prints a message and returns `1` if a source file cannot be
|
||||
loaded instead of exiting Bats.
|
||||
Aside from that `bats_load_safe` acts exactly like `load`.
|
||||
|
||||
As pointed out by @iatrou in https://www.tldp.org/LDP/abs/html/declareref.html,
|
||||
using the `declare` builtin restricts scope of a variable. Thus, since actual
|
||||
`source`-ing is performed in context of the `load` function, `declare`d symbols
|
||||
will _not_ be made available to callers of `load`.
|
||||
|
||||
### `load` argument resolution
|
||||
|
||||
`load` supports the following arguments:
|
||||
|
||||
- absolute paths
|
||||
- relative paths (to the current test file)
|
||||
|
||||
> For backwards compatibility `load` first searches for a file ending in
|
||||
> `.bash` (e.g. `load test_helper` searches for `test_helper.bash` before
|
||||
> it looks for `test_helper`). This behaviour is deprecated and subject to
|
||||
> change, please use exact filenames instead.
|
||||
|
||||
If `argument` is an absolute path `load` tries to determine the load
|
||||
path directly.
|
||||
|
||||
If `argument` is a relative path or a name `load` looks for a matching
|
||||
path in the directory of the current test.
|
||||
|
||||
## `bats_load_library`: Load system wide libraries
|
||||
|
||||
Some libraries are installed on the system, e.g. by `npm` or `brew`.
|
||||
These should not be `load`ed, as their path depends on the installation method.
|
||||
Instead, one should use `bats_load_library` together with setting
|
||||
`BATS_LIB_PATH`, a `PATH`-like colon-delimited variable.
|
||||
|
||||
`bats_load_library` has two modes of resolving requests:
|
||||
|
||||
1. by relative path from the `BATS_LIB_PATH` to a file in the library
|
||||
2. by library name, expecting libraries to have a `load.bash` entrypoint
|
||||
|
||||
For example if your `BATS_LIB_PATH` is set to
|
||||
`~/.bats/libs:/usr/lib/bats`, then `bats_load_library test_helper`
|
||||
would look for existing files with the following paths:
|
||||
|
||||
- `~/.bats/libs/test_helper`
|
||||
- `~/.bats/libs/test_helper/load.bash`
|
||||
- `/usr/lib/bats/test_helper`
|
||||
- `/usr/lib/bats/test_helper/load.bash`
|
||||
|
||||
The first existing file in this list will be sourced.
|
||||
|
||||
If you want to load only part of a library or the entry point is not named `load.bash`,
|
||||
you have to include it in the argument:
|
||||
`bats_load_library library_name/file_to_load` will try
|
||||
|
||||
- `~/.bats/libs/library_name/file_to_load`
|
||||
- `~/.bats/libs/library_name/file_to_load/load.bash`
|
||||
- `/usr/lib/bats/library_name/file_to_load`
|
||||
- `/usr/lib/bats/library_name/file_to_load/load.bash`
|
||||
|
||||
Apart from the changed lookup rules, `bats_load_library` behaves like `load`.
|
||||
|
||||
__Note:__ As seen above `load.bash` is the entry point for libraries and
|
||||
meant to load more files from its directory or other libraries.
|
||||
|
||||
__Note:__ Obviously, the actual `BATS_LIB_PATH` is highly dependent on the environment.
|
||||
To maintain a uniform location across systems, (distribution) package maintainers
|
||||
are encouraged to use `/usr/lib/bats/` as the install path for libraries where possible.
|
||||
However, if the package manager has another preferred location, like `npm` or `brew`,
|
||||
you should use this instead.
|
||||
|
||||
## `skip`: Easily skip tests
|
||||
|
||||
Tests can be skipped by using the `skip` command at the point in a test you wish
|
||||
to skip.
|
||||
|
||||
```bash
|
||||
@test "A test I don't want to execute for now" {
|
||||
skip
|
||||
run foo
|
||||
[ "$status" -eq 0 ]
|
||||
}
|
||||
```
|
||||
|
||||
Optionally, you may include a reason for skipping:
|
||||
|
||||
```bash
|
||||
@test "A test I don't want to execute for now" {
|
||||
skip "This command will return zero soon, but not now"
|
||||
run foo
|
||||
[ "$status" -eq 0 ]
|
||||
}
|
||||
```
|
||||
|
||||
Or you can skip conditionally:
|
||||
|
||||
```bash
|
||||
@test "A test which should run" {
|
||||
if [ foo != bar ]; then
|
||||
skip "foo isn't bar"
|
||||
fi
|
||||
|
||||
run foo
|
||||
[ "$status" -eq 0 ]
|
||||
}
|
||||
```
|
||||
|
||||
__Note:__ `setup` and `teardown` hooks still run for skipped tests.
|
||||
|
||||
## `setup` and `teardown`: Pre- and post-test hooks
|
||||
|
||||
You can define special `setup` and `teardown` functions, which run before and
|
||||
after each test case, respectively. Use these to load fixtures, set up your
|
||||
environment, and clean up when you're done.
|
||||
|
||||
You can also define `setup_file` and `teardown_file`, which will run once before
|
||||
the first test's `setup` and after the last test's `teardown` for the containing
|
||||
file. Variables that are exported in `setup_file` will be visible to all following
|
||||
functions (`setup`, the test itself, `teardown`, `teardown_file`).
|
||||
|
||||
Similarly, there is `setup_suite` (and `teardown_suite`) which run once before (and
|
||||
after) all tests of the test run.
|
||||
|
||||
__Note:__ As `setup_suite` and `teardown_suite` are intended for all files in a suite,
|
||||
they must be defined in a separate `setup_suite.bash` file. Automatic discovery works
|
||||
by searching for `setup_suite.bash` in the folder of the first `*.bats` file of the suite.
|
||||
If this automatism does not work for your usecase, you can work around by specifying
|
||||
`--setup-suite-file` on the `bats` command. If you have a `setup_suite.bash`, it must define
|
||||
`setup_suite`! However, defining `teardown_suite` is optional.
|
||||
|
||||
<!-- markdownlint-disable MD033 -->
|
||||
<details>
|
||||
<summary>Example of setup/{,_file,_suite} (and teardown{,_file,_suite}) call order</summary>
|
||||
For example the following call order would result from two files (file 1 with
|
||||
tests 1 and 2, and file 2 with test3) with a corresponding `setup_suite.bash` file being tested:
|
||||
|
||||
```text
|
||||
setup_suite # from setup_suite.bash
|
||||
setup_file # from file 1, on entering file 1
|
||||
setup
|
||||
test1
|
||||
teardown
|
||||
setup
|
||||
test2
|
||||
teardown
|
||||
teardown_file # from file 1, on leaving file 1
|
||||
setup_file # from file 2, on enter file 2
|
||||
setup
|
||||
test3
|
||||
teardown
|
||||
teardown_file # from file 2, on leaving file 2
|
||||
teardown_suite # from setup_suite.bash
|
||||
```
|
||||
|
||||
</details>
|
||||
<!-- markdownlint-enable MD033 -->
|
||||
|
||||
Note that the `teardown*` functions can fail a test, if their return code is nonzero.
|
||||
This means, using `return 1` or having the last command in teardown fail, will
|
||||
fail the teardown. Unlike `@test`, failing commands within `teardown` won't
|
||||
trigger failure as ERREXIT is disabled.
|
||||
|
||||
<!-- markdownlint-disable MD033 -->
|
||||
<details>
|
||||
<summary>Example of different teardown failure modes</summary>
|
||||
|
||||
```bash
|
||||
teardown() {
|
||||
false # this will fail the test, as it determines the return code
|
||||
}
|
||||
|
||||
teardown() {
|
||||
false # this won't fail the test ...
|
||||
echo some more code # ... and this will be executed too!
|
||||
}
|
||||
|
||||
teardown() {
|
||||
return 1 # this will fail the test, but the rest won't be executed
|
||||
echo some more code
|
||||
}
|
||||
|
||||
teardown() {
|
||||
if true; then
|
||||
false # this will also fail the test, as it is the last command in this function
|
||||
else
|
||||
true
|
||||
fi
|
||||
}
|
||||
```
|
||||
|
||||
</details>
|
||||
<!-- markdownlint-enable MD033 -->
|
||||
|
||||
## `bats_require_minimum_version <Bats version number>`
|
||||
|
||||
Added in [v1.7.0](https://github.com/bats-core/bats-core/releases/tag/v1.7.0)
|
||||
|
||||
Code for newer versions of Bats can be incompatible with older versions.
|
||||
In the best case this will lead to an error message and a failed test suite.
|
||||
In the worst case, the tests will pass erroneously, potentially masking a failure.
|
||||
|
||||
Use `bats_require_minimum_version <Bats version number>` to avoid this.
|
||||
It communicates in a concise manner, that you intend the following code to be run
|
||||
under the given Bats version or higher.
|
||||
|
||||
Additionally, this function will communicate the current Bats version floor to
|
||||
subsequent code, allowing e.g. Bats' internal warning to give more informed warnings.
|
||||
|
||||
__Note__: By default, calling `bats_require_minimum_version` with versions before
|
||||
Bats 1.7.0 will fail regardless of the required version as the function is not
|
||||
available. However, you can use the
|
||||
[bats-backports plugin](https://github.com/bats-core/bats-backports) to make
|
||||
your code usable with older versions, e.g. during migration while your CI system
|
||||
is not yet upgraded.
|
||||
|
||||
## Code outside of test cases
|
||||
|
||||
In general you should avoid code outside tests, because each test file will be evaluated many times.
|
||||
However, there are situations in which this might be useful, e.g. when you want to check for dependencies
|
||||
and fail immediately if they're not present.
|
||||
|
||||
In general, you should avoid printing outside of `@test`, `setup*` or `teardown*` functions.
|
||||
Have a look at section [printing to the terminal](#printing-to-the-terminal) for more details.
|
||||
## File descriptor 3 (read this if Bats hangs)
|
||||
|
||||
Bats makes a separation between output from the code under test and output that
|
||||
forms the TAP stream (which is produced by Bats internals). This is done in
|
||||
order to produce TAP-compliant output. In the [Printing to the
|
||||
terminal](#printing-to-the-terminal) section, there are details on how to use
|
||||
file descriptor 3 to print custom text properly.
|
||||
|
||||
A side effect of using file descriptor 3 is that, under some circumstances, it
|
||||
can cause Bats to block and execution to seem dead without reason. This can
|
||||
happen if a child process is spawned in the background from a test. In this
|
||||
case, the child process will inherit file descriptor 3. Bats, as the parent
|
||||
process, will wait for the file descriptor to be closed by the child process
|
||||
before continuing execution. If the child process takes a lot of time to
|
||||
complete (eg if the child process is a `sleep 100` command or a background
|
||||
service that will run indefinitely), Bats will be similarly blocked for the same
|
||||
amount of time.
|
||||
|
||||
**To prevent this from happening, close FD 3 explicitly when running any command
|
||||
that may launch long-running child processes**, e.g. `command_name 3>&-` .
|
||||
|
||||
## Printing to the terminal
|
||||
|
||||
Bats produces output compliant with [version 12 of the TAP protocol](https://testanything.org/tap-specification.html). The
|
||||
produced TAP stream is by default piped to a pretty formatter for human
|
||||
consumption, but if Bats is called with the `-t` flag, then the TAP stream is
|
||||
directly printed to the console.
|
||||
|
||||
This has implications if you try to print custom text to the terminal. As
|
||||
mentioned in [File descriptor 3](#file-descriptor-3-read-this-if-bats-hangs),
|
||||
bats provides a special file descriptor, `&3`, that you should use to print
|
||||
your custom text. Here are some detailed guidelines to refer to:
|
||||
|
||||
- Printing **from within a test function**:
|
||||
- First you should consider if you want the text to be always visible or only
|
||||
when the test fails. Text that is output directly to stdout or stderr (file
|
||||
descriptor 1 or 2), ie `echo 'text'` is considered part of the test function
|
||||
output and is printed only on test failures for diagnostic purposes,
|
||||
regardless of the formatter used (TAP or pretty).
|
||||
- To have text printed unconditionally from within a test function you need to
|
||||
redirect the output to file descriptor 3, eg `echo 'text' >&3`. This output
|
||||
will become part of the TAP stream. You are encouraged to prepend text printed
|
||||
this way with a hash (eg `echo '# text' >&3`) in order to produce 100% TAP compliant
|
||||
output. Otherwise, depending on the 3rd-party tools you use to analyze the
|
||||
TAP stream, you can encounter unexpected behavior or errors.
|
||||
|
||||
- Printing **from within the `setup*` or `teardown*` functions**: The same hold
|
||||
true as for printing with test functions.
|
||||
|
||||
- Printing **outside test or `setup*`/`teardown*` functions**:
|
||||
- You should avoid printing in free code: Due to the multiple executions
|
||||
contexts (`setup_file`, multiple `@test`s) of test files, output
|
||||
will be printed more than once.
|
||||
|
||||
- Regardless of where text is redirected to (stdout, stderr or file descriptor 3)
|
||||
text is immediately visible in the terminal, as it is not piped into the formatter.
|
||||
|
||||
- Text printed to stdout may interfere with formatters as it can
|
||||
make output non-compliant with the TAP spec. The reason for this is that
|
||||
such output will be produced before the [_plan line_][tap-plan] is printed,
|
||||
contrary to the spec that requires the _plan line_ to be either the first or
|
||||
the last line of the output.
|
||||
|
||||
- Due to internal pipes/redirects, output to stderr is always printed first.
|
||||
|
||||
[tap-plan]: https://testanything.org/tap-specification.html#the-plan
|
||||
|
||||
## Special variables
|
||||
|
||||
There are several global variables you can use to introspect on Bats tests:
|
||||
|
||||
- `$BATS_RUN_COMMAND` is the run command used in your test case.
|
||||
- `$BATS_TEST_FILENAME` is the fully expanded path to the Bats test file.
|
||||
- `$BATS_TEST_DIRNAME` is the directory in which the Bats test file is located.
|
||||
- `$BATS_TEST_NAMES` is an array of function names for each test case.
|
||||
- `$BATS_TEST_NAME` is the name of the function containing the current test case.
|
||||
- `BATS_TEST_NAME_PREFIX` will be prepended to the description of each test on
|
||||
stdout and in reports.
|
||||
- `$BATS_TEST_DESCRIPTION` is the description of the current test case.
|
||||
- `BATS_TEST_RETRIES` is the maximum number of additional attempts that will be
|
||||
made on a failed test before it is finally considered failed.
|
||||
The default of 0 means the test must pass on the first attempt.
|
||||
- `BATS_TEST_TIMEOUT` is the number of seconds after which a test (including setup)
|
||||
will be aborted and marked as failed. Updates to this value in `setup()` or `@test`
|
||||
cannot change the running timeout countdown, so the latest useful update location
|
||||
is `setup_file()`.
|
||||
- `$BATS_TEST_NUMBER` is the (1-based) index of the current test case in the test file.
|
||||
- `$BATS_SUITE_TEST_NUMBER` is the (1-based) index of the current test case in the test suite (over all files).
|
||||
- `$BATS_TEST_TAGS` the tags of the current test.
|
||||
- `$BATS_TMPDIR` is the base temporary directory used by bats to create its
|
||||
temporary files / directories.
|
||||
(default: `$TMPDIR`. If `$TMPDIR` is not set, `/tmp` is used.)
|
||||
- `$BATS_RUN_TMPDIR` is the location to the temporary directory used by bats to
|
||||
store all its internal temporary files during the tests.
|
||||
(default: `$BATS_TMPDIR/bats-run-$BATS_ROOT_PID-XXXXXX`)
|
||||
- `$BATS_FILE_EXTENSION` (default: `bats`) specifies the extension of test files that should be found when running a suite (via `bats [-r] suite_folder/`)
|
||||
- `$BATS_SUITE_TMPDIR` is a temporary directory common to all tests of a suite.
|
||||
Could be used to create files required by multiple tests.
|
||||
- `$BATS_FILE_TMPDIR` is a temporary directory common to all tests of a test file.
|
||||
Could be used to create files required by multiple tests in the same test file.
|
||||
- `$BATS_TEST_TMPDIR` is a temporary directory unique for each test.
|
||||
Could be used to create files required only for specific tests.
|
||||
- `$BATS_VERSION` is the version of Bats running the test.
|
||||
|
||||
## Libraries and Add-ons
|
||||
|
||||
Bats supports loading external assertion libraries and helpers. Those under `bats-core` are officially supported libraries (integration tests welcome!):
|
||||
|
||||
- <https://github.com/bats-core/bats-assert> - common assertions for Bats
|
||||
- <https://github.com/bats-core/bats-support> - supporting library for Bats test helpers
|
||||
- <https://github.com/bats-core/bats-file> - common filesystem assertions for Bats
|
||||
- <https://github.com/bats-core/bats-detik> - e2e tests of applications in K8s environments
|
||||
|
||||
and some external libraries, supported on a "best-effort" basis:
|
||||
|
||||
- <https://github.com/ztombol/bats-docs> (still relevant? Requires review)
|
||||
- <https://github.com/grayhemp/bats-mock> (as per #147)
|
||||
- <https://github.com/jasonkarns/bats-mock> (how is this different from grayhemp/bats-mock?)
|
||||
@@ -0,0 +1,9 @@
|
||||
Here are the docs of following versions:
|
||||
|
||||
* [v1.2.0](../../v1.2.0/README.md)
|
||||
* [v1.1.0](../../v1.1.0/README.md)
|
||||
* [v1.0.2](../../v1.0.2/README.md)
|
||||
* [v0.4.0](../../v0.4.0/README.md)
|
||||
* [v0.3.1](../../v0.3.1/README.md)
|
||||
* [v0.2.0](../../v0.2.0/README.md)
|
||||
* [v0.1.0](../../v0.1.0/README.md)
|
||||
Reference in New Issue
Block a user