shunit2-users Mailing List for shunit2
Brought to you by:
sfsetse
Menu
▾
▴
shunit2-users — Users of shUnit2
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
(2) |
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
(1) |
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
|
Mar
(9) |
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Alex H. <ale...@gm...> - 2017-07-04 07:56:40
|
Hi all, I have discovered the project on Github: https://github.com/kward/shunit2 I assume I can raise this as an issue there and send in a pull request. Thanks, alex On 3 July 2017 at 16:39, Alex Harvey <ale...@gm...> wrote: > Hi all, > > I write about this question I asked at Stack Overflow here: > stackoverflow.com/questions/44870065/stubbing-file-tests- > in-shunit2/44870101 > > As pointed out in that post, it is possible to stub the shell file tests > using code like: > > [() { > case "$*" in > "-x /usr/local/rvm/bin/rvm") > false > ;; > esac > } > > > Unfortunately, this breaks shUnit2 itself. > > It is suggested in the above that this issue could be avoided if all calls > to external commands in shUnit2 were prefixed by command: > > E.g. instead of (on line 17) > > [ -n "${SHUNIT_VERSION:-}" ] && exit 0 > > > we would have > > command [ -n "${SHUNIT_VERSION:-}" ] && exit 0 > > > I tested this - and applied to a few other commands that a user might want > to stub, like rm, mkdir, cat etc. > > Is it possible for me to send in a patch? Does anyone see any potential > issue with what I am proposing here? > > Thanks, > Alex > > > > |
|
From: Alex H. <ale...@gm...> - 2017-07-03 06:39:54
|
Hi all, I write about this question I asked at Stack Overflow here: stackoverflow.com/questions/44870065/stubbing-file-tests-in-shunit2/44870101 As pointed out in that post, it is possible to stub the shell file tests using code like: [() { case "$*" in "-x /usr/local/rvm/bin/rvm") false ;; esac } Unfortunately, this breaks shUnit2 itself. It is suggested in the above that this issue could be avoided if all calls to external commands in shUnit2 were prefixed by command: E.g. instead of (on line 17) [ -n "${SHUNIT_VERSION:-}" ] && exit 0 we would have command [ -n "${SHUNIT_VERSION:-}" ] && exit 0 I tested this - and applied to a few other commands that a user might want to stub, like rm, mkdir, cat etc. Is it possible for me to send in a patch? Does anyone see any potential issue with what I am proposing here? Thanks, Alex |
|
From: Kate W. <kat...@fo...> - 2010-04-09 10:13:03
|
shUnit2 is available for Gentoo Linux as well. Here is a mirror to a ebuild. http://mirror.leaseweb.com/pub/software/gentoo-x86-portage/dev-util/shunit2/ Two other libraries I've written, shFlags and log4sh are available via Blastwave for Solaris (they are maintained by a coworker of mine) if you want to look at them too. http://www.opencsw.org/packages/log4sh http://www.opencsw.org/packages/shflags I hadn't designed shUnit2 to be sourced into the environment and run at any time, but there is no reason that wouldn't work. Even for that use case though, it should be sourced with '.' and doesn't need the executable bit. The only thing I can think of (there may be more) for needing executable permissions is to test a non-executable shell script (no #! line, and no . sourcing line within the script needing to know where shunit2 is). $ shunit2 /path/to/some/unit_test.sh For the use case of a distribution (or rather multiple distributions) where the location of shUnit2 changes between them, going the sourcing route like you mention could be very advantageous. It's something I hadn't thought about. File a bug (if there isn't one) and I'll think about what needs to change. - kate On Fri, Apr 2, 2010 at 9:12 PM, lyase damasked <ly...@gm...> wrote: > I would think you are right there is not just one "good" location for the > file. > specially if some example ships with it or parallel and can "runs" > without failures in such a way that they stay that way between > releases of shunit2 on the distro. if this constraint is not too > binding to the development of shunit2. this may look like a very nice > feature to the release process so the maintenance of the user's > scripts be minimal. I didn't see shunit2 in other distro. I noticed in > the source the example's path have to be constant at least in relative > terms to the folder of shunit2. I am unsure if as users we should > assume . that will not change. > > I had been using shunit from tarball hence had the same issue of > being path dependent. which ended up been a real pain and high costs > (dropping the tests......). > i apologize my proposal to help is becoming more an enhancement & more > work on your sides. > let me just say i really like your stuff and hope to be using it for a > while. > > Lyase. > > > On Fri, Apr 2, 2010 at 9:06 AM, Ulrich Dangel <mr...@sp...> wrote: > > On Thursday 01 April 2010 13:11:20 lyase damasked wrote: > >> Sorry my mistake I did not know about the '.' operator.my tests looks > >> to be working well. > >> with > >> .-rw-r--r-- 1 root root 31191 2009-12-06 16:11 shunit2 > >> thanks for the great job. I love it. > >> lyase. > > > > Actually there is some slightly difference. If you make shunit2 > executable > > and put it into your PATH it is possible to load shunit2 directly via > > . shunit2 without specifying a path. > > What is the proposed way of installing shunit2 in a distribution? > > Any other distributions ships shunit2? If yes where do they put the file? > > > > The benefit would be that you do not have to specify the path for the > > shunit2 file, which could now easily change. > > > > > > Ulrich > > > -- Kate Ward <kat...@fo...> |
|
From: lyase d. <ly...@gm...> - 2010-04-02 20:12:13
|
I would think you are right there is not just one "good" location for the file. specially if some example ships with it or parallel and can "runs" without failures in such a way that they stay that way between releases of shunit2 on the distro. if this constraint is not too binding to the development of shunit2. this may look like a very nice feature to the release process so the maintenance of the user's scripts be minimal. I didn't see shunit2 in other distro. I noticed in the source the example's path have to be constant at least in relative terms to the folder of shunit2. I am unsure if as users we should assume . that will not change. I had been using shunit from tarball hence had the same issue of being path dependent. which ended up been a real pain and high costs (dropping the tests......). i apologize my proposal to help is becoming more an enhancement & more work on your sides. let me just say i really like your stuff and hope to be using it for a while. Lyase. On Fri, Apr 2, 2010 at 9:06 AM, Ulrich Dangel <mr...@sp...> wrote: > On Thursday 01 April 2010 13:11:20 lyase damasked wrote: >> Sorry my mistake I did not know about the '.' operator.my tests looks >> to be working well. >> with >> .-rw-r--r-- 1 root root 31191 2009-12-06 16:11 shunit2 >> thanks for the great job. I love it. >> lyase. > > Actually there is some slightly difference. If you make shunit2 executable > and put it into your PATH it is possible to load shunit2 directly via > . shunit2 without specifying a path. > What is the proposed way of installing shunit2 in a distribution? > Any other distributions ships shunit2? If yes where do they put the file? > > The benefit would be that you do not have to specify the path for the > shunit2 file, which could now easily change. > > > Ulrich > |
|
From: Ulrich D. <mr...@sp...> - 2010-04-02 07:06:47
|
On Thursday 01 April 2010 13:11:20 lyase damasked wrote: > Sorry my mistake I did not know about the '.' operator.my tests looks > to be working well. > with > .-rw-r--r-- 1 root root 31191 2009-12-06 16:11 shunit2 > thanks for the great job. I love it. > lyase. Actually there is some slightly difference. If you make shunit2 executable and put it into your PATH it is possible to load shunit2 directly via . shunit2 without specifying a path. What is the proposed way of installing shunit2 in a distribution? Any other distributions ships shunit2? If yes where do they put the file? The benefit would be that you do not have to specify the path for the shunit2 file, which could now easily change. Ulrich |
|
From: lyase d. <ly...@gm...> - 2010-04-01 11:11:35
|
Sorry my mistake I did not know about the '.' operator.my tests looks
to be working well.
with
.-rw-r--r-- 1 root root 31191 2009-12-06 16:11 shunit2
thanks for the great job. I love it.
lyase.
On Mon, Mar 29, 2010 at 1:33 AM, Kate Ward <kat...@fo...> wrote:
> shunit2 itself should never need to be executable when used in the manner
> described. Scripts that are sourced in using the '.' operator don't need the
> executable bit set.
> There was a request long ago to make shunit2 take the name of a separate
> script on its command line that it would then test, but I've never gone to
> the effort to make that change. As such, I've never written it to be
> executed.
>
> - kate
>
> On Thu, Mar 25, 2010 at 1:21 PM, lyase damasked <ly...@gm...> wrote:
>>
>> shunit2 is called as follows in the scripts with the test . it will
>> have to be executable to work.
>>
>> #! /bin/sh
>> # file:willPass_test.sh
>> testEquality()
>> {
>> assertEquals 1 1
>> }
>> # load shunit2
>> . /usr/share/shunit2/shunit2
>> ____________________________________________________________________
>> if you package the examples . for squeeze be aware that the path for
>> shunit2 in the original sources shunit2-2.1.5 is
>> . ../src/shell/shunit2
>> so that may have to be patched in all the examples.
>> in fact to my understanding shunit2 should go into /usr/bin
>> now for the build dependent.
>> if you run make (which builts the documentation before building the
>> package you will find it needs xsltproc &unzip. now it is true that
>> your package does not included the docs . and kate mentioned a shift
>> DocBook been replaced with ReStructuredText. in the lastest versions.
>> Lyase
>>
>>
>> ------------------------------------------------------------------------------
>> Download Intel® Parallel Studio Eval
>> Try the new software tools for yourself. Speed compiling, find bugs
>> proactively, and fine-tune applications for parallel performance.
>> See why Intel Parallel Studio got high marks during beta.
>> http://p.sf.net/sfu/intel-sw-dev
>> _______________________________________________
>> shunit2-users mailing list
>> shu...@li...
>> https://lists.sourceforge.net/lists/listinfo/shunit2-users
>
>
>
> --
> Kate Ward <kat...@fo...>
>
|
|
From: Kate W. <kat...@fo...> - 2010-03-28 23:33:11
|
shunit2 itself should never need to be executable when used in the manner
described. Scripts that are sourced in using the '.' operator don't need the
executable bit set.
There was a request long ago to make shunit2 take the name of a separate
script on its command line that it would then test, but I've never gone to
the effort to make that change. As such, I've never written it to be
executed.
- kate
On Thu, Mar 25, 2010 at 1:21 PM, lyase damasked <ly...@gm...> wrote:
> shunit2 is called as follows in the scripts with the test . it will
> have to be executable to work.
>
> #! /bin/sh
> # file:willPass_test.sh
> testEquality()
> {
> assertEquals 1 1
> }
> # load shunit2
> . /usr/share/shunit2/shunit2
> ____________________________________________________________________
> if you package the examples . for squeeze be aware that the path for
> shunit2 in the original sources shunit2-2.1.5 is
> . ../src/shell/shunit2
> so that may have to be patched in all the examples.
> in fact to my understanding shunit2 should go into /usr/bin
> now for the build dependent.
> if you run make (which builts the documentation before building the
> package you will find it needs xsltproc &unzip. now it is true that
> your package does not included the docs . and kate mentioned a shift
> DocBook been replaced with ReStructuredText. in the lastest versions.
> Lyase
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> shunit2-users mailing list
> shu...@li...
> https://lists.sourceforge.net/lists/listinfo/shunit2-users
>
--
Kate Ward <kat...@fo...>
|
|
From: lyase d. <ly...@gm...> - 2010-03-25 12:21:43
|
shunit2 is called as follows in the scripts with the test . it will
have to be executable to work.
#! /bin/sh
# file:willPass_test.sh
testEquality()
{
assertEquals 1 1
}
# load shunit2
. /usr/share/shunit2/shunit2
____________________________________________________________________
if you package the examples . for squeeze be aware that the path for
shunit2 in the original sources shunit2-2.1.5 is
. ../src/shell/shunit2
so that may have to be patched in all the examples.
in fact to my understanding shunit2 should go into /usr/bin
now for the build dependent.
if you run make (which builts the documentation before building the
package you will find it needs xsltproc &unzip. now it is true that
your package does not included the docs . and kate mentioned a shift
DocBook been replaced with ReStructuredText. in the lastest versions.
Lyase
|
|
From: Ulrich D. <mr...@sp...> - 2010-03-24 21:35:28
|
* lyase damasked wrote [24.03.10 15:29]:
> as i was using/testing shunit2 in squeeze.
Cool.
> I would like to propose 2 changes in the package
> and 2 wishes:
>
> 1) change path of shlib
> so the make command runs without error when unpacking the source
> in /bin/docbookPrep.sh line 121.
> from:
> . "${MY_DIR}/../lib/sh/shlib"
> to:
> . "${MY_DIR}/../lib//shlib"
Hm, I'll have to think it carefully as it is not needed in the debian
package.
But yes, this is a bug in the release tarball, and should be fixed
upstream. Please note that there are already multiple issues regarding
this bug in the bugtracker
<http://code.google.com/p/shunit2/issues/list>
> 2)
>
> change in debian/rules line 29 permissions settings:
> from:
> install -m 644 src/shell/shunit2
> $(CURDIR)/debian/shunit2/usr/share/ shunit2
> to:
> install -m 605 src/shell/shunit2
> $(CURDIR)/debian/shunit2/usr/share/ shunit2
> so the srcipt is executable.
Why? I currently don't see a benefit if shunit2 is executable. What is
your usecase?
> wish 1;
> when installing install the examples too.
Ok, I think it would be a extra package.
> wish2:
> add xsltproc unzip in build dependants. so the package can be rebuilt easily.
Hm, no, as currently it is not necessary for the build process.
Ulrich
|
|
From: Kate W. <kat...@fo...> - 2010-03-24 21:34:44
|
Great to hear! I definitely don't have the time to maintain the OS packages. At the moment, I'm trying to finally setup a set of VMware instances using VMware server so that I can do automated testing of a bunch of OSes. I recently found a bug under FreeBSD (on my FreeNAS box) that I fixed, and if my fix is good, I'll make a 2.1.6 release. - kate On Wed, Mar 24, 2010 at 9:21 PM, Ulrich Dangel <mr...@sp...> wrote: > * Kate Ward wrote [24.03.10 21:21]: > > Hi Kate, > > first of all, great and nice software. > > > I don't maintain the Debian package, but perhaps whoever does, they might > > like to jump to the 2.1 release as it is quite stable. > > I am the maintainer of the debian package. And I am currently using > 2.1.5 which is as far as i know the latest release. The package > currently only ships the manual and not the examples. But i will change > that. > > regards, > Ulrich > -- Kate Ward <kat...@fo...> |
|
From: Ulrich D. <mr...@sp...> - 2010-03-24 21:21:24
|
* Kate Ward wrote [24.03.10 21:21]: Hi Kate, first of all, great and nice software. > I don't maintain the Debian package, but perhaps whoever does, they might > like to jump to the 2.1 release as it is quite stable. I am the maintainer of the debian package. And I am currently using 2.1.5 which is as far as i know the latest release. The package currently only ships the manual and not the examples. But i will change that. regards, Ulrich |
|
From: Kate W. <kat...@fo...> - 2010-03-24 20:53:10
|
Hi Lyase,
I'm glad you like the software, and glad it is useful for you.
The things you mention are only part of the 2.0 series of the software. In
the 2.1 series of the software, I've done away with the usage of DocBook and
replaced it with ReStructuredText, which is much easier to maintain. I've
also made exactly the suggestion you mentioned regarding the lib/shlib path.
I don't maintain the Debian package, but perhaps whoever does, they might
like to jump to the 2.1 release as it is quite stable. That said, I should
make a 2.2 release just to indicate how stable the code base is.
- kate
On Wed, Mar 24, 2010 at 2:29 PM, lyase damasked <ly...@gm...> wrote:
> as i was using/testing shunit2 in squeeze.
> I would like to propose 2 changes in the package
> and 2 wishes:
>
> 1) change path of shlib
> so the make command runs without error when unpacking the source
> in /bin/docbookPrep.sh line 121.
> from:
> . "${MY_DIR}/../lib/sh/shlib"
> to:
> . "${MY_DIR}/../lib//shlib"
>
> 2)
>
> change in debian/rules line 29 permissions settings:
> from:
> install -m 644 src/shell/shunit2
> $(CURDIR)/debian/shunit2/usr/share/ shunit2
> to:
> install -m 605 src/shell/shunit2
> $(CURDIR)/debian/shunit2/usr/share/ shunit2
> so the srcipt is executable.
> wish 1;
> when installing install the examples too.
> wish2:
> add xsltproc unzip in build dependants. so the package can be rebuilt
> easily.
>
> thanks, I hope that helps. and thanks all for what's already built it
> is a great piece of work for testing.
>
> Lyase
>
>
> ------------------------------------------------------------------------------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> shunit2-users mailing list
> shu...@li...
> https://lists.sourceforge.net/lists/listinfo/shunit2-users
>
--
Kate Ward <kat...@fo...>
|
|
From: lyase d. <ly...@gm...> - 2010-03-24 14:29:42
|
as i was using/testing shunit2 in squeeze.
I would like to propose 2 changes in the package
and 2 wishes:
1) change path of shlib
so the make command runs without error when unpacking the source
in /bin/docbookPrep.sh line 121.
from:
. "${MY_DIR}/../lib/sh/shlib"
to:
. "${MY_DIR}/../lib//shlib"
2)
change in debian/rules line 29 permissions settings:
from:
install -m 644 src/shell/shunit2
$(CURDIR)/debian/shunit2/usr/share/ shunit2
to:
install -m 605 src/shell/shunit2
$(CURDIR)/debian/shunit2/usr/share/ shunit2
so the srcipt is executable.
wish 1;
when installing install the examples too.
wish2:
add xsltproc unzip in build dependants. so the package can be rebuilt easily.
thanks, I hope that helps. and thanks all for what's already built it
is a great piece of work for testing.
Lyase
|
|
From: lyase d. <ly...@gm...> - 2010-03-17 06:17:50
|
after unzipping the archive shunit2-2.1.5.tgz
running make gave an error.
about shlib not been found.
i am not expert but here is a patch I would like to submit.
let me know how i should make &submit my changes and if they useful.
the idea been:
1) to correct the path of shlib in docbookPrep.sh
I still have small things i'd like to change but i will start with this and
see how it goes.
in the debian squeeze distribution I had the following issues:
I) could not find the examples after running apt-get install shunit2.
II) the default permission settings gives
"/usr/share/shunit2/shunit2 Permission denied."
when i try to run my tests. as a user.
of course i changed that in my system but it would probably be best if
the deb package can be fixed.
Lyase
____________________________________________________________first.patch_________________________________________________
diff -U 3 -H -d -r -N -- shunit2-2.1.5/bin/docbookPrep.sh
shunit2-2.1.5_local/bin/docbookPrep.sh
--- shunit2-2.1.5/bin/docbookPrep.sh 2009-12-03 22:46:34.000000000 +0100
+++ shunit2-2.1.5_local/bin/docbookPrep.sh 2010-03-16
08:16:50.000000000 +0100
@@ -21,7 +21,7 @@
MY_DIR=`dirname "$0"`
# load shlib
-. "${MY_DIR}/../lib/sh/shlib"
+. "${MY_DIR}/../lib/shlib"
BASE_DIR=`shlib_relToAbsPath "${MY_DIR}/.."`
DL_DIR="${BASE_DIR}/tmp"
|
|
From: lyase d. <ly...@gm...> - 2010-03-17 06:03:27
|
I am having an error when running make. I did a small patch but I can't get it in the mailing list. please let me know how i can submit my patch. thanks, Lyase |
|
From: Dick R. <rre...@la...> - 2009-05-26 22:44:06
|
This package is a real treat. I'm interested in modular construction in which each function is written in its own file. The final product, be it a final script or a unit testing script would be constructed by absorbing functions with #include directives. The C preprocessor seems like a natural choice for building those scripts, but it barfs on bang-lines (#! /bin/sh) and shell comments because they do not conform to C syntax. Does anyone know of something that processess #includes or the equivalent, with recursion, and nice error messages, like the C pre-processor but on arbitrary text files? thanks, Dick |
|
From: Kate W. <kat...@fo...> - 2008-08-30 16:28:36
|
[+cc shu...@go...]
Hi Mario,
Honestly, you're the first to say much about it. I agree that it feels
broke, and I've wondered exactly how to fix it.
I modeled shUnit2 as close to JUnit 3.8.2 as I could. Looking at the code
for failNotEquals() in JUnit, I see:
static public void failNotEquals(String message,
Object expected,
Object actual) {
fail(format(message, expected, actual));
}
Looking at the code for fail(), I see:
static public void fail(String message) {
throw new AssertionFailedError(message);
}
And format():
static String format(String message,
Object expected,
Object actual) {
String formatted= "";
if (message != null)
formatted= message+" ";
return formatted+"expected:<"+expected+"> but was:<"+actual+">";
}
So, basically, it does absolutely nothing. Now, I don't disagree that this
is the wrong approach, but I just haven't taken the time to really look into
this.
Looking at the patch you sent as part of the bug, it looks like a start to
fixing the problem, but the unit tests fail with that patch. I'll update the
bug at Google asking that you submit a new patch that fixes the unit tests
as well.
- kate
On Wed, Aug 20, 2008 at 3:28 PM, Mario Sanchez Prada <msa...@ig...>wrote:
> Hi all,
>
> First of all, congratulations for your work on shUnit2. I was really
> impressed on how easy was to use it and how clean a testing suite is
> thanks to your awesome script. I really like it a lot, sincerely, I was
> looking for something like this all over the internet and it is exactly
> what I needed, so thank you a lot :-)
>
> So, as I'm really happy, here you are my first contribution:
>
> As you could check out in the bugzilla...
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=2062264&group_id=188001&atid=923569
>
> ...I submitted today what I think it's a bug in the shUnit2 script, both
> in its 2.0 and 2.1 versions.
>
> The bug is about failNotEqual, failSame and failNotSame functions being
> probably wrong, since they always result on failures, regardless of the
> parameters used being the the same or not.
>
> Perhaps I'm misunderstanding something (documentation is a bit confuse
> as well about some of those three functions) so don't hesitate to
> correct me if you think so. Nevertheless, according to how I think those
> functions should work I attached a patch in the bugzilla with the fixes
> I implemented in my local copy, which I'm using right now and seem to be
> working right. Feel free to take a look into it and give me your
> opinions).
>
> I'm also attaching a dummy test file I used to test the framework
> provided by shUnit2, so you can check the bug out as well, in case you
> wish to do it so.
>
> Hope it helps,
>
> Br,
>
> Mario
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> shunit2-users mailing list
> shu...@li...
> https://lists.sourceforge.net/lists/listinfo/shunit2-users
>
>
--
Kate Ward <kat...@fo...>
|
|
From: Mario S. P. <msa...@ig...> - 2008-08-20 14:28:54
|
Hi all, First of all, congratulations for your work on shUnit2. I was really impressed on how easy was to use it and how clean a testing suite is thanks to your awesome script. I really like it a lot, sincerely, I was looking for something like this all over the internet and it is exactly what I needed, so thank you a lot :-) So, as I'm really happy, here you are my first contribution: As you could check out in the bugzilla... http://sourceforge.net/tracker/index.php?func=detail&aid=2062264&group_id=188001&atid=923569 ...I submitted today what I think it's a bug in the shUnit2 script, both in its 2.0 and 2.1 versions. The bug is about failNotEqual, failSame and failNotSame functions being probably wrong, since they always result on failures, regardless of the parameters used being the the same or not. Perhaps I'm misunderstanding something (documentation is a bit confuse as well about some of those three functions) so don't hesitate to correct me if you think so. Nevertheless, according to how I think those functions should work I attached a patch in the bugzilla with the fixes I implemented in my local copy, which I'm using right now and seem to be working right. Feel free to take a look into it and give me your opinions). I'm also attaching a dummy test file I used to test the framework provided by shUnit2, so you can check the bug out as well, in case you wish to do it so. Hope it helps, Br, Mario |
|
From: Kate W. <kat...@fo...> - 2008-06-05 22:11:35
|
That will depend on which shell you are using. Could you send me that and I
can take a look? Basically what I will look at is passing a custom message
with the data you need.
If you are using bash, the following should work. Basically, you just need
to send a custom message to the assert functions that give the info you
need. (note the assertTrue line is one long line; there are 3 lines listed
total below)
expect=1999
result=`date '+%Y'`
assertTrue "$0:${BASH_LINENO:-}: ASSERT: expected:<${expect}> but was
:<${result}>" ${expect} ${result}
Getting this to be automatic might work by modifying each method in the
shUnit2 library to give such output. I'll have to look into that, so I will
take this as a feature request.
- kate
On Tue, Jun 3, 2008 at 11:06 PM, Olexiy Buyanskyy <ol...@gm...> wrote:
> Hi,
>
> Is it possible to print line number and file name for each error?
>
> mytest.sh:15: ASSERT: It's not 1999 :-( This is 2008. expected:<1999> but
> was:<2008>
>
> I need that feature for eclipse error parsing and highlighting.
>
>
> Olexiy
>
--
Kate Ward <kat...@fo...>
|
|
From: Kate W. <kat...@fo...> - 2008-05-11 00:06:23
|
Hello, I just wanted to announce to everyone that the latest release of shUnit2 is now available. This release improves zsh support, and makes testing from automated frameworks easier. download link – http://downloads.sourceforge.net/shunit2/shunit2-2.1.3.tgz release notes – http://shunit2.svn.sourceforge.net/svnroot/shunit2/tags/source/2.1.3/doc/RELEASE_NOTES-2.1.3.txt - kate -- Kate Ward <kat...@fo...> |
|
From: Malcolm G. <M.G...@bo...> - 2007-08-22 00:18:59
|
Hi Kate, =20 Yes, that would explain it. I used Firefox to download shunit2-2.0.3.tgz =20 It's not something you have any control over. Perhaps Sourceforge could provide some generic download tips to cover these situations. The same considerations must be relevant to other projects on Sourceforge. =20 It was for me a surprising problem that could easily discourage potential shunit2 users. =20 Getting shunit2 working was a breeze. =20 Cheers, Mal. =20 Malcolm Gorman m.g...@bo... <mailto:m.g...@bo...> Phone (03) 9669 4846 FAX (03) 9669 4128 Australian Bureau of Meteorology 700 Collins Street GPO Box 1289=20 Docklands, VIC 3008 Melbourne, VIC 3001 Intranet: http://aifsa-ho.bom.gov.au/~mal <http://aifsa-ho.bom.gov.au/~mal> =20 Tsunamis: http://web.bom.gov.au/nob/nmoc/tsunami <http://web.bom.gov.au/nob/nmoc/tsunami> <http://web.bom.gov.au/~mal/tsunami>=20 =20 ________________________________ From: Kate Ward [mailto:kat...@fo...]=20 Sent: Tuesday, 21 August 2007 23:20 To: Malcolm Gorman Cc: Bob Proulx; shu...@li... Subject: Re: [Shunit2-users] shunit2-2.0.3.tgz format [SEC=3DUNCLASSIFIED] =09 =09 Hi Malcolm, =09 I have often had Firefox and Mozilla automatically gunzip the file for me without asking or even telling me that it was doing so. I'm guessing it was something like this that happened. Did you verify the MD5 sum after downloading to that on the site? My guess is that they didn't match.=20 =09 - kate =09 =09 On 8/21/07, Bob Proulx <bo...@pr...> wrote:=20 Malcolm Gorman wrote: > I tried to gunzip shunit2-2.0.3.tgz without success, on a unix system. =09 This works fine for me. Could you show us the error message that you received? I believe that it should work for you as well.=20 =09 tar tvzf shunit2-2.0.3.tgz tar xvzf shunit2-2.0.3.tgz =09 Or more verbosely: =09 gzip -d < shunit2-2.0.3.tgz | tar tvf - gzip -d < shunit2-2.0.3.tgz | tar xvf - =09 Or even more verbosely using explicit files. This is not preferred=20 because it uncompresses the original file but is illustrative of the component parts of the process. =09 gzip -d shunit2-2.0.3.tgz tar tvf shunit2-2.0.3.tar tar xvf shunit2-2.0.3.tar =09 What error message are you seeing from any of the above cases?=20 =09 Bob =09 =09 ------------------------------------------------------------------------ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser.=20 Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ shunit2-users mailing list shu...@li... =09 https://lists.sourceforge.net/lists/listinfo/shunit2-users =09 --=20 Kate Ward <kat...@fo...>=20 |
|
From: Kate W. <kat...@fo...> - 2007-08-21 13:20:02
|
Hi Malcolm, I have often had Firefox and Mozilla automatically gunzip the file for me without asking or even telling me that it was doing so. I'm guessing it was something like this that happened. Did you verify the MD5 sum after downloading to that on the site? My guess is that they didn't match. - kate On 8/21/07, Bob Proulx <bo...@pr...> wrote: > > Malcolm Gorman wrote: > > I tried to gunzip shunit2-2.0.3.tgz without success, on a unix system. > > This works fine for me. Could you show us the error message that you > received? I believe that it should work for you as well. > > tar tvzf shunit2-2.0.3.tgz > tar xvzf shunit2-2.0.3.tgz > > Or more verbosely: > > gzip -d < shunit2-2.0.3.tgz | tar tvf - > gzip -d < shunit2-2.0.3.tgz | tar xvf - > > Or even more verbosely using explicit files. This is not preferred > because it uncompresses the original file but is illustrative of the > component parts of the process. > > gzip -d shunit2-2.0.3.tgz > tar tvf shunit2-2.0.3.tar > tar xvf shunit2-2.0.3.tar > > What error message are you seeing from any of the above cases? > > Bob > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > shunit2-users mailing list > shu...@li... > https://lists.sourceforge.net/lists/listinfo/shunit2-users > -- Kate Ward <kat...@fo...> |
|
From: <bo...@pr...> - 2007-08-21 10:00:41
|
Malcolm Gorman wrote: > I tried to gunzip shunit2-2.0.3.tgz without success, on a unix system. This works fine for me. Could you show us the error message that you received? I believe that it should work for you as well. tar tvzf shunit2-2.0.3.tgz tar xvzf shunit2-2.0.3.tgz Or more verbosely: gzip -d < shunit2-2.0.3.tgz | tar tvf - gzip -d < shunit2-2.0.3.tgz | tar xvf - Or even more verbosely using explicit files. This is not preferred because it uncompresses the original file but is illustrative of the component parts of the process. gzip -d shunit2-2.0.3.tgz tar tvf shunit2-2.0.3.tar tar xvf shunit2-2.0.3.tar What error message are you seeing from any of the above cases? Bob |
|
From: Kate W. <kat...@fo...> - 2007-07-13 10:09:02
|
Hello, I just wanted to announce that the latest stable and development releases of shUnit2 are now available. Both releases are a realignment with the JUnit code base (v4.3.1specifically) and the development release contains new support for test skipping. Download links: 2.0.3 http://downloads.sourceforge.net/shunit2/shunit2-2.0.3.tgz 2.1.1 http://downloads.sourceforge.net/shunit2/shunit2-2.1.1.tgz <http://downloads.sourceforge.net/shunit2/shunit2-2.1.0.tgz> - kate -- Kate Ward <kat...@fo...> |
|
From: Kate W. <kat...@fo...> - 2007-04-23 16:45:45
|
Here is a corrected download link. I must learn to remove the URL and replace it rather than just editing it :-( http://downloads.sourceforge.net/shunit2/shunit2-2.0.2.tgz - kate On 4/22/07, Kate Ward <kat...@fo...> wrote: > > Hello, > > I just wanted to announce to everyone that the latest release of shUnit2 > is now available. > > This release fixes a couple of user submitted bugs, and fixes an issue > with the links in the documentation not working. > > download link -- http://downloads.sourceforge.net/shunit2/shunit2-2.0.2.tgz > <http://downloads.sourceforge.net/shunit2/shunit2-2.0.0.tgz> > release notes -- http://sourceforge.net/project/shownotes.php?release_id=503091&group_id=188001 > > <http://sourceforge.net/project/shownotes.php?release_id=487983&group_id=188001> > > - kate > > -- > Kate Ward <kat...@fo...> -- Kate Ward <kat...@fo...> |
1 message has been excluded from this view by a project administrator.
