ATatsaloli·Mar 2, 2021
See also https://github.com/sstephenson/bats
In Bash_unit – bash unit testing frameworksstephenson
bats
Shell2011–2021
sstephenson / bats · Archived
bats
Bash Automated Testing System
13Distinct people
14Mentions
0Explicit recommenders
7.1KGitHub stars
What to know before exploring
What it is
Bash Automated Testing System
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year14 dated mentions
Observed mentions: 2011-12-30 20:20:11 UTC to 2021-03-02 11:34:05 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2011 | 2011-01-01 00:00:00 UTC | 2012-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2012 | 2012-01-01 00:00:00 UTC | 2013-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
14 sourcesLooks like it was finally forked https://github.com/sstephenson/bats/issues/150
In Testing Dolt using BATS (Bash Automated Testing System)https://github.com/sstephenson/bats
sstephenson/bats: Bash Automated Testing System - GitHub
In Ask HN: Any suggestion on how to test CLI applications?Ask HN: Any suggestion on how to test CLI applications?
Hello HN!
I've been looking at alternatives on how to test command line applications, specifically, for example, exit codes, output messages and whatnot. I've seen "bats" https://github.com/sstephenson/bats and Bazel for testing but I'm curious as what other tools people use in a day to day basis. UI testing is nice with tools like Cypress.io and maybe there's something out there that isn't as popular but it's useful.
Thoughts?
3 points · Open discussionThe poster is holding a line of bash to the standard of code and is illustrating that readability should be the goal and a way of bringing bash commands to a standard of readability for something like a PR. Readability is really there to show _intent_
I would say though that if you are bringing this to the code standards of today then this should really be wrapped up in some kind of unit test (https://github.com/sstephenson/bats )for it to pass the PR. That would make the code a bit more maintainable and can be integrated as a stage in your CI/CD pipeline.
If we do that then the intent would be clarified by the input and the expected output of the test. Then then the code would at least be maintainable and the readability problem becomes less of an issue when it comes to technical debt.
I've done this plenty of times with my teams and its
Read the rest
certainly helped.
The poster is holding a line of bash to the standard of code and is illustrating that readability should be the goal and a way of bringing bash commands to a standard of readability for something like a PR. Readability is really there to show _intent_
I would say though that if you are bringing this to the code standards of today then this should really be wrapped up in some kind of unit test (https://github.com/sstephenson/bats )for it to pass the PR. That would make the code a bit more maintainable and can be integrated as a stage in your CI/CD pipeline.
If we do that then the intent would be clarified by the input and the expected output of the test. Then then the code would at least be maintainable and the readability problem becomes less of an issue when it comes to technical debt.
I've done this plenty of times with my teams and its
Read the rest
certainly helped.
I know you're asking about pre-deploy, but for post-deployment, you might want to check out Bash Automated Testing System (BATS) [0].
[0] https://github.com/sstephenson/bats
In Ask HN: How to check/enforce best practices on infrastructure?Python has something similar:
https://docs.python.org/3/library/doctest.html
For software with a command-line interface, perhaps it would be useful to do some testing at that interface, perhaps using BATS:
https://github.com/sstephenson/bats
That is also automatically tested, but describes the actual user interface.
In A README maturity modelThe point of my shell project Oil (http://www.oilshell.org/blog/) is to get rid of the shell vs. Python debate.
My claim is that, in general, X isn’t a good bash replacement, where X is Python/Ruby/Perl/JavaScript. I think that’s obvious to some people but not to others (typically X programmers who don’t know shell, which was me in the not-too-distant past).
This article is good because it has a port of a realistic port from shell to Python. But to me it only succeeds in proving the opposite point -- that porting to Python is a lot of effort, and the result has a lot of detail that doesn't match the problem domain. Error handling is possible, which is good, but awkward. And now you need external librariesl like psutil, then a package manager and special deployment tools for Python. (And you probably need some shell scripts to build/de
Read the rest
ploy your Python...)
One thing I don't see is the complete result, which from the looks of it is pretty clunky compared to the 20 or so lines of bash.
-----
About Oil: I realized that not everyone was getting the point of it, so I resolved to write an “elevator pitch” [2].
I haven’t published that post yet, but the pitch is: Oil is the language you can convert bash scripts to automatically, once they become a maintenance problem
That might happen at 50 lines for some people or 1000 lines for other people.
Oil will have a more uniform syntax [6], not 4 different sublanguages [3]. It will get rid of word splitting, and have proper arrays [4] and hash tables. It should be easy to write a test framework in it, as opposed to bash test frameworks like bats [5] which actually modify/extend the language because it's not powerful enough.
There are some cases where porting from bash to Python is a good idea. But I also had the revelation of porting Python to shell, and being relieved (e.g. more than one deployment script). I was a Python person and I came at it from the opposite side. Shell is really expressive, but it’s hampered horrible syntax and a bad/old implementation.
In summary, the conundrum of porting things back and forth between bash <=> Python/Ruby/Perl/JavaScript is why Oil exists. It seems like this debate will never end, and I hope that the “automatic conversion” property [6] is a unique argument in favor of Oil vs. X.
If anyone is skeptical of my elevator pitch I’m interested in the feedback :) You can also try the first release [7].
[1] http://www.oilshell.org/
[2] http://www.oilshell.org/blog/2017/07/31.html
[3] http://www.oilshell.org/blog/2016/10/26.html
[4] http://www.oilshell.org/blog/2016/11/06.html
[5] https://github.com/sstephenson/bats
[6] http://www.oilshell.org/blog/2017/02/05.html
[7] http://www.oilshell.org/blog/2017/07/23.html
I've used bats[1] in the past. I also recommend the command line shellcheck[2] for linting.
[1] https://github.com/sstephenson/bats
[2] https://github.com/koalaman/shellcheck
In Ansible 2.0 releasedBATS looks great, but it might not be maintained any more: https://github.com/sstephenson/bats/issues
In Defensive BASH programmingAll these recommendation are excellent (except omitting the necessary obsessive quoting of all variables everywhere (just in case they contain a space).
I've been enjoying BATS [0] for my bash testing.
[1] https://github.com/sstephenson/bats
In Defensive BASH programmingTesting might be less of a common practice for quick shell scripts, but it can be done and there's nothing particularly difficult about it, compared to other languages. Especially with "pure" scripts that don't revolve around system effects... which is the case with other scripting languages too.
As for static typing, agreed, though considering that shell is basically a scriptable FFI, real static typing would probably add a lot of complexity? Attempts at "typed shell" don't seem to go over well, maybe due to "worse is better" dynamics.
BTW, re: testing shell scripts: https://github.com/sstephenson/bats
In GitHub: Scaling on Ruby, with a nomadic tech teamBats: TAP-compatible testing for Bash
41 points · Open discussion