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 <j...@debian.org> Date : 04/10/2016 12:02 (GMT+01:00) À : Pascal Grange <pas...@grange.nom.fr>, 839...@bugs.debian.org Cc : debian-de...@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 <pas...@grange.nom.fr> > > * Package name : bash-unit > Version : 1.0.2 > Upstream Author : Pascal Grange <pas...@grange.nom.fr> > * 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.
