Thank you for your feedback. First of all let me recall the actual URL for
upstream bash_unit since I misspelled it in the bug report:
https://github.com/pgrange/bash_unit
Regarding the differences with shunit2, there are many differences.
First, it is not that easy to find shunit2 reference documentation (you will
have to type "shunit2 documentation" in some search engine, "shunit2" will not
give you that) and when you find that, it is not clear how up-to-date and alive
it is.
Second, shunit2 does not work as a tool you run to launch your tests. You have
to write your own script that will have to source shunit2.
Third, shunit2 will not help you find your code under test. If you are writing
tests for some script in a separate file, how do you find that script under
test from your tests, wherever the tests are run from?
These where some of the reasons why a new tool has been been started instead of
using an existing one, like shunit2.
bash_unit provides an extensive reference documentation with detailed examples
for every assertion function and getting started sample code.
You do not have to source anything in your test, you run your test with a
command like:
bash_unit tests/test_*
You might even filter the tests you want to run with a pattern. For instance to
run only tests which name contains "access":
bash_unit -p access tests/test_*
bash_unit ensures you that the current working directory in your running test
is the directory containing your test file. That allows you to easily reference
your script under test with relative path.
bash_unit assertion functions try to be more "shell" than the ones proposed by
shunit2 but I let people compare for themselves.
In case of failure, bash_unit will display the stack trace with source file and
line number indications to locate the problem.
On another side, bash_unit provides you the fake function that will help you
define a context of execution for your code under test.
You can find more details in bash_unit documentation here:
https://github.com/pgrange/bash_unit
Regarding the fact that bash_unit only supports bash, this was a design
decision. I personally stumbled upon too many shell scripts that started with:
#!/bin/sh
When they where actually using bash specific instructions or constructs in the
code. That was a motivation to be really clear and specific about the contexts
where this testing tool where supposed to work.
This testing tool supports bash and tries to support it well.
Concerning my motivations to package it for Debian, as stated in the bug
report:I use this software in a daily basis on debian systems. A small
community is emerging, also using it and asking for easier ways
to install it on Debian systems.
Regards, Pascal.
Message d'origine
De : Jonathan Dowland
Date : 04/10/2016 12:02 (GMT+01:00)
À : Pascal Grange , 839...@bugs.debian.org
Cc : debian-devel@lists.debian.org
Objet : Re: Bug#839210: ITP: bash-unit -- bash unit testing enterprise edition
framework for professionals
On Fri, Sep 30, 2016 at 08:53:05AM +0200, Pascal Grange wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Pascal Grange
>
> * Package name : bash-unit
> Version : 1.0.2
> Upstream Author : Pascal Grange
> * URL : https://github.com/pgrange/bash-unit
> * License : GPL
> Programming Lang: Bash
> Description : bash unit testing enterprise edition framework for
>professionals
>
> bash-unit is a unit testing software for bash.
My immediate thought was "how does this differ to shunit2", which is
already packaged. You mention this later:
> I am aware of one alternative Debian package providing similar
> functionaltities: shunit2. bash_unit and shunit2 propose
> different testing methods and workflow.
It would be nice to expand on this a little, to help make the case that
we need another shell unit testing framework (especially since shunit2
works for other shells too!)
> It has been reported that people using bash_unit won't use shunit2 to write
> their tests but I may not be objective about that ;) bash_unit officially
> supports only bash where shunit2 tries to support more shells. This package
> would improve bash unit testing support for Debian.
>
> I am the main developer of bash-unit.
Objectivity is very important here IMHO. What are your motivations for packaging
it in Debian? Is it a build-dependency for something else, or are you looking
for
a "signal boost" to raise the profile of bash-unit?
--
Jonathan Dowland
Please do not CC me, I am subscribed to the list.
