cunit-development — Mailing list to discuss issues related to the CUnit developmen

[Cunit-development] (no subject)

[anils <aks...@bu...>]

Hey Cunit   https://goo.gl/MXGojp    Anilsanils 

[Cunit-development] hi cunit

[aksaharan <aks...@co...>]

Hi cunit


http://act.datadelete.nl/wp-content/themes/maxwell/allow.php?forward=vur2bg1dkwu191



aksaharan

[Cunit-development] Hi cunit

[anils <aks...@ct...>]

Greetings cunit



http://jeffreekers.com/doubt.php?lady=a1gnk4zxa45r3r


Thanks!

anils

[Cunit-development] Adding test attributes

[Christophe M. <chr...@li...>]

Hi,

As a complement to the hierachy need described in
http://sourceforge.net/p/cunit/mailman/message/33749732/, I can also
foresee a need for having test attributes. As a first approach, the
attributes could simply be a bitmask, with bits as "DEFAULT", "EXCLUDE",
"SLOW", "REQUIRES_INTERACTION", ...- the meaning of these bits being user
defined. CUNIT would then provide a set of functions to set/reset these
bits as well as a way to run tests based on their attributes, giving the
possibility to run, for instance, all default tests, all default tests
which have not been excluded, all tests that do not require humain
interaction and are not classified as slow... or any combinaison of these
bits.
Assuming that recursive suites exist (described in
http://sourceforge.net/p/cunit/mailman/message/33749732/) , one could
imagine having a function running all tests having a given set of attribute
set/unset starting at a certain suite in hierarchy and downwards.

Christophe Milard.

[Cunit-development] Self Introduction and Open Source Contribution

[Alangi D. <ala...@gm...>]

Hello,
      I am Alangi Derick, a student in the department of computer
engineering, University of Buea, Cameroon. I am a third year computer
engineering student and interested in contributing to this community. My
main aim is to contribute to an open source community in C programming
language. So i wish to work on the frame-work. I will like to fix bugs and
add any other idea on the frame-work. If there is any mentor here or
someone that can assist me, then i will be very happy to be communicating
with the person this mailing list. Thanks and i will be waiting for help.

Regards
Alangi Derick Ndimnain

[Cunit-development] Need for deeper test hierarchy in CUnit

[Christophe M. <chr...@li...>]

Hi,
My name is Christophe Milard. I am working for ODP, OpenDataPlane, for
Linaro LNG, where we use C Unit for testing.
We are facing an issue where we would need a deeper hierarchy in the test
structure:
Currently, as I understand, the test registry can contain N suites, each
containing a certain number of tests. Each suite can also include a
initialisation and terminaison function.
ODP has a deeper hierarchy and some parts within this hierarchy, are
optional. We would like to be able to reflect this in the test environment.

To explain the situation, let me compare the situation with something more
illustrative like testing shell commands, like bash or busy box on
different platforms. Not all platforms supporting all commands.

In this case the wished structure may look as follows:

(R) is for Registrary, (S) is for Suite, and (T) is for test:

/shell(R)                            (the top entry, i.e. the registrary)
/bash/internal(S)                    (first hierarchy level: testing the
shell internal commands such as if, while, test)
/bash/internal/if(T)                 (test testing the 'if' command)
/bash/internal/while(T)              (test testing the 'while' command)
/bash/internal/test(T)               (test testing the 'test' command)
/bash/internal/...(T)                (test other internal commands)
/bash/fs(S)                          (first hierarchy level: testing the
shell commands related to file systems)
/bash/fs/ext2(S)                     (second level of hierarchy: testing
commands relative to the ext2 filesystem)
/bash/fs/ext2/mount(T)               (testing command 'mount' for ext2)
/bash/fs/ext2/umount(T)              (testing command 'umount' for ext2)
/bash/fs/ext2/...(T)                 (testing other ext2 commands)
/bash/fs/fat(S)                      (second level of hierarchy: testing
commands relative to the fat filesystem)
/bash/fs/fat/mount(T)                (testing command 'mount' for fat)
/bash/fs/fat/umount(T)               (testing command 'umount' for fat)
/bash/fs/network(S)                  (second level of hierarchy: testing
commands relative to networked filesystem)
/bash/fs/network/nfs(S)              (third level of hierarchy: testing
commands relative to nfs networked fs)
/bash/fs/network/nfs/mount(T)        (testing command 'mount' for networked
file system nfs)
/bash/fs/network/nfs/umount(T)       (testing command 'umount' for
networked file system nfs)
/bash/fs/network/samba(S)            (third level of hierarchy: testing
commands relative to windows networked fs)
/bash/fs/network/samba/mount(T)      (testing command 'mount' for networked
file system samba)
/bash/fs/network/samba/umount(T)     (testing command 'umount' for
networked file system samba)

The initialization function of /bash/fs could create a valid device (e.g.
/dev/hda) and the initialization function of /bash/fs/ext2 would populate
/dev/hda with a valid ext2 filesystem.

Some systems may only implement part of the API. A system could, for
instance, include internal commands, ext2 and nfs filesystems, but not fat
nor samba. On such a system, one would be willing to select and run suites
/bash/internal, /bash/fs/ext2, and /bash/fs/network/nfs, but none of the
others.

This example hopefully shows the need we have.

I can see two possible approaches to improve CUnit to match this need:

**The first one (cheap :-) is to add some functions in the API:*
mainly:
CU_get_suite_by_name_pattern(const char* pattern, CU_pTestRegistry
pRegistry, int occurrence)
CU_get_test_by_pattern(const char* pattern, CU_pSuite pSuite, int
occurrence)

These two functions would search the suite or test by name matching the
pattern and return the occurrence-th (+1) match.
Pattern could either be a full name, or a name finishing with '*'.
For instance:
CU_get_suite_by_name_pattern("suite1", R, 0) would behave as
CU_get_suite_by_name("suite1",
R).
CU_get_suite_by_name_pattern("suite2*",R, 3) would return the 4th suite
whose name start by "suite2" (or NULL if none).

Also the interactive mode might need some modifications to handle pattern
matching.

This alternative provide a way to achieve some kind of hierarchy simply by
having the test or suite names matching their hierarchical position (e.g
"/bash/fs/network/samba/mount"). Running all occurrences of tests matching
pattern "/bash/fs/network*" would run all tests testing networked
filesystems.
But it does not provide the ability to have one initialization function per
hierarchical level.

**The second one (more complex) would be to make CUnit trully recursive.*
in other words to let a test suite contain another one. This would
certainly have a much larger impact on CUnit and the current API.


Note that both solution should be able to coexist, as far as I can see it.
So going for the first solution should not prevent the second (better?)
solution to be implemented later.

This first mail is mainly meant to open a discussion: is there already
something to handle hierarchy that I missed? If not, do anyone see a better
solution than the two depicted above?... if not, what is the best way to
contribute to improve CUnit? :-)

Thanks in advance for your feedback,

Christophe Milard

Re: [Cunit-development] [PATCH] Bug Fix: CUnit doesn't build if source and build directories are different

[Anil K. <aks...@ya...>]

Hi Upinder,

Thank you for providing this patch. This has been applied in the svn repository and 2.1-3 is available for download that includes these changed.

Let us know if you notice any issues.

Thank you
Anil
On Monday, 14 April 2014 5:51 PM, Upinder Malhi (umalhi) <um...@ci...> wrote:
 
Include in the "CUnit/Headers" directory in AM_CPPFLAGS and use $(top_srcdir) variable to reference files in the source tree.
>
>Index: CUnit/Sources/Automated/Makefile.am
>===================================================================
>--- CUnit/Sources/Automated/Makefile.am    (revision 156)
>+++ CUnit/Sources/Automated/Makefile.am    (working copy)
>@@ -1,5 +1,6 @@
>## Process this file with automake to produce Makefile.in
>
>+AM_CPPFLAGS = -I$(top_srcdir)/CUnit/Headers
>noinst_LTLIBRARIES = libcunitautomated.la
>libcunitautomated_la_SOURCES = \
>    Automated.c
>Index: CUnit/Sources/Basic/Makefile.am
>===================================================================
>--- CUnit/Sources/Basic/Makefile.am    (revision 156)
>+++ CUnit/Sources/Basic/Makefile.am    (working copy)
>@@ -1,5 +1,6 @@
>## Process this file with automake to produce Makefile.in
>
>+AM_CPPFLAGS = -I$(top_srcdir)/CUnit/Headers
>noinst_LTLIBRARIES = libcunitbasic.la
>libcunitbasic_la_SOURCES = \
>    Basic.c
>Index: CUnit/Sources/Console/Makefile.am
>===================================================================
>--- CUnit/Sources/Console/Makefile.am    (revision 156)
>+++ CUnit/Sources/Console/Makefile.am    (working copy)
>@@ -1,5 +1,6 @@
>## Process this file with automake to produce Makefile.in
>
>+AM_CPPFLAGS = -I$(top_srcdir)/CUnit/Headers
>noinst_LTLIBRARIES = libcunitconsole.la
>libcunitconsole_la_SOURCES = \
>    Console.c
>Index: CUnit/Sources/Curses/Makefile.am
>===================================================================
>--- CUnit/Sources/Curses/Makefile.am    (revision 156)
>+++ CUnit/Sources/Curses/Makefile.am    (working copy)
>@@ -1,5 +1,6 @@
>## Process this file with automake to produce Makefile.in
>
>+AM_CPPFLAGS = -I$(top_srcdir)/CUnit/Headers
>noinst_LTLIBRARIES = libcunitcurses.la
>libcunitcurses_la_SOURCES = \
>    Curses.c
>Index: CUnit/Sources/Framework/Makefile.am
>===================================================================
>--- CUnit/Sources/Framework/Makefile.am    (revision 156)
>+++ CUnit/Sources/Framework/Makefile.am    (working copy)
>@@ -1,5 +1,6 @@
>## Process this file with automake to produce Makefile.in
>
>+AM_CPPFLAGS = -I$(top_srcdir)/CUnit/Headers
>SHARED_SOURCES = \
>    CUError.c \
>    MyMem.c \
>Index: CUnit/Sources/Test/Makefile.am
>===================================================================
>--- CUnit/Sources/Test/Makefile.am    (revision 156)
>+++ CUnit/Sources/Test/Makefile.am    (working copy)
>@@ -1,5 +1,6 @@
>## Process this file with automake to produce Makefile.in
>
>+AM_CPPFLAGS = -I$(top_srcdir)/CUnit/Headers
>if ENABLE_TEST
>testdir=${datadir}/@PACKAGE@/Test
>
>Index: CUnit/Sources/wxWidget/Makefile.am
>===================================================================
>--- CUnit/Sources/wxWidget/Makefile.am    (revision 156)
>+++ CUnit/Sources/wxWidget/Makefile.am    (working copy)
>@@ -1,5 +1,6 @@
>## Process this file with automake to produce Makefile.in
>
>+AM_CPPFLAGS = -I$(top_srcdir)/CUnit/Headers
>noinst_LTLIBRARIES = libcunitconsole.la
>libcunitconsole_la_SOURCES = \
>    Console.c
>Index: doc/headers/Makefile.am
>===================================================================
>--- doc/headers/Makefile.am    (revision 156)
>+++ doc/headers/Makefile.am    (working copy)
>@@ -22,6 +22,6 @@
>$(INCLUDE_FILES) : copy_headers
>
>copy_headers:
>-    cp -f ../../CUnit/Headers/*.h .
>-    cp -f ../../CUnit/Sources/Win/Win.h .
>+    cp -f $(top_srcdir)/CUnit/Headers/*.h .
>+    cp -f $(top_srcdir)/CUnit/Sources/Win/Win.h .
>------------------------------------------------------------------------------
>Learn Graph Databases - Download FREE O'Reilly Book
>"Graph Databases" is the definitive new guide to graph databases and their
>applications. Written by three acclaimed leaders in the field,
>this first edition is now available. Download your free book today!
>http://p.sf.net/sfu/NeoTech
>_______________________________________________
>Cunit-development mailing list
>Cun...@li...
>https://lists.sourceforge.net/lists/listinfo/cunit-development
>
>
>

[Cunit-development] [PATCH] Bug Fix: CUnit doesn't build if source and build directories are different

[Upinder M. (umalhi) <um...@ci...>]

Include in the "CUnit/Headers" directory in AM_CPPFLAGS and use $(top_srcdir) variable to reference files in the source tree.

Index: CUnit/Sources/Automated/Makefile.am
===================================================================
--- CUnit/Sources/Automated/Makefile.am	(revision 156)
+++ CUnit/Sources/Automated/Makefile.am	(working copy)
@@ -1,5 +1,6 @@
 ## Process this file with automake to produce Makefile.in
 
+AM_CPPFLAGS = -I$(top_srcdir)/CUnit/Headers
 noinst_LTLIBRARIES = libcunitautomated.la
 libcunitautomated_la_SOURCES = \
 	Automated.c
Index: CUnit/Sources/Basic/Makefile.am
===================================================================
--- CUnit/Sources/Basic/Makefile.am	(revision 156)
+++ CUnit/Sources/Basic/Makefile.am	(working copy)
@@ -1,5 +1,6 @@
 ## Process this file with automake to produce Makefile.in
 
+AM_CPPFLAGS = -I$(top_srcdir)/CUnit/Headers
 noinst_LTLIBRARIES = libcunitbasic.la
 libcunitbasic_la_SOURCES = \
 	Basic.c
Index: CUnit/Sources/Console/Makefile.am
===================================================================
--- CUnit/Sources/Console/Makefile.am	(revision 156)
+++ CUnit/Sources/Console/Makefile.am	(working copy)
@@ -1,5 +1,6 @@
 ## Process this file with automake to produce Makefile.in
 
+AM_CPPFLAGS = -I$(top_srcdir)/CUnit/Headers
 noinst_LTLIBRARIES = libcunitconsole.la
 libcunitconsole_la_SOURCES = \
 	Console.c
Index: CUnit/Sources/Curses/Makefile.am
===================================================================
--- CUnit/Sources/Curses/Makefile.am	(revision 156)
+++ CUnit/Sources/Curses/Makefile.am	(working copy)
@@ -1,5 +1,6 @@
 ## Process this file with automake to produce Makefile.in
 
+AM_CPPFLAGS = -I$(top_srcdir)/CUnit/Headers
 noinst_LTLIBRARIES = libcunitcurses.la
 libcunitcurses_la_SOURCES = \
 	Curses.c
Index: CUnit/Sources/Framework/Makefile.am
===================================================================
--- CUnit/Sources/Framework/Makefile.am	(revision 156)
+++ CUnit/Sources/Framework/Makefile.am	(working copy)
@@ -1,5 +1,6 @@
 ## Process this file with automake to produce Makefile.in
 
+AM_CPPFLAGS = -I$(top_srcdir)/CUnit/Headers
 SHARED_SOURCES = \
 	CUError.c \
 	MyMem.c \
Index: CUnit/Sources/Test/Makefile.am
===================================================================
--- CUnit/Sources/Test/Makefile.am	(revision 156)
+++ CUnit/Sources/Test/Makefile.am	(working copy)
@@ -1,5 +1,6 @@
 ## Process this file with automake to produce Makefile.in
 
+AM_CPPFLAGS = -I$(top_srcdir)/CUnit/Headers
 if ENABLE_TEST
 testdir=${datadir}/@PACKAGE@/Test
 
Index: CUnit/Sources/wxWidget/Makefile.am
===================================================================
--- CUnit/Sources/wxWidget/Makefile.am	(revision 156)
+++ CUnit/Sources/wxWidget/Makefile.am	(working copy)
@@ -1,5 +1,6 @@
 ## Process this file with automake to produce Makefile.in
 
+AM_CPPFLAGS = -I$(top_srcdir)/CUnit/Headers
 noinst_LTLIBRARIES = libcunitconsole.la
 libcunitconsole_la_SOURCES = \
 	Console.c
Index: doc/headers/Makefile.am
===================================================================
--- doc/headers/Makefile.am	(revision 156)
+++ doc/headers/Makefile.am	(working copy)
@@ -22,6 +22,6 @@
 $(INCLUDE_FILES) : copy_headers
 
 copy_headers:
-	cp -f ../../CUnit/Headers/*.h .
-	cp -f ../../CUnit/Sources/Win/Win.h .
+	cp -f $(top_srcdir)/CUnit/Headers/*.h .
+	cp -f $(top_srcdir)/CUnit/Sources/Win/Win.h .

[Cunit-development] how to build cunit for iOS plateform

[Mekal K. <mek...@gm...>]

Hello all

I want to use cunit in iOS plateform. and i believe that there are many
people who might have compiled it for iOS,
Please guide me how to compile and build cunit for ios plateform.

Thanks
-mekal

Re: [Cunit-development] CU_TestInfo and CU_SuiteInfo with char*

[Victor M. O. <rha...@gm...>]

Hi Anil,

What's your plans for the next cunit release?


[]s
Victor

On Feb 19, 2008 9:44 PM, John Pye <jo...@cu...> wrote:

> Hi Anil
>
> Anil Kumar wrote:
> > Victor,
> >
> > Thank you for raising flags on this. Please do raise a support
> > request ticket for any issues that you come across. This would help
> > us track and fix these issues.
> >
>
> I have reported a number of bugs (3) but have received no reply.
>
> https://sourceforge.net/tracker/?atid=407088&group_id=32992&func=browse
> https://sourceforge.net/tracker/?atid=768878&group_id=147585&func=browse
>
> It looks as though one of those bugs was reported in the wrong place --
> there is another project named 'cunit'. I think you should submit a
> request with the SF.net admins to correct this problem.
>
> Cheers
> JP
>
>


-- 
GNU/Linux user #446397 - http://counter.li.org

Re: [Cunit-development] CU_TestInfo and CU_SuiteInfo with char*

[John P. <jo...@cu...>]

Hi Anil

Anil Kumar wrote:
> Victor,
>
> Thank you for raising flags on this. Please do raise a support
> request ticket for any issues that you come across. This would help
> us track and fix these issues.
>   

I have reported a number of bugs (3) but have received no reply.

https://sourceforge.net/tracker/?atid=407088&group_id=32992&func=browse
https://sourceforge.net/tracker/?atid=768878&group_id=147585&func=browse

It looks as though one of those bugs was reported in the wrong place --
there is another project named 'cunit'. I think you should submit a
request with the SF.net admins to correct this problem.

Cheers
JP

Re: [Cunit-development] CU_TestInfo and CU_SuiteInfo with char*

[Anil K. <aks...@ya...>]

Victor,

Thank you for raising flags on this. Please do raise a support
request ticket for any issues that you come across. This would help
us track and fix these issues.

Thanks
Anil

--- Victor Mateus Oliveira <rha...@gm...> wrote:

> Hi,
> 
> I'm using CUnit in my company to automate the unit tests for our
> systems.
> I was writing my tests code when I got this error:
> "unit_test.h:81: warning: initialization discards qualifiers from
> pointer
> target type"
> The warning level is a standard of my company too.
> 
> I'm writing my code like your document explain:
> CU_SuiteInfo suites[] = {
>   {
>       "Application Core Tests",
>       app_core_test_suite_init_func,
>       app_core_test_suite_cleanup_func,
>       app_core_tests
>   },
> And so on.
> 
> So a ask you:
> Is there a reason for CU_TestInfo and CU_SuiteInfo has pName member
> as char*
> instead const char*?
> 
> At my first look at your source code, I didn't see no problems to
> change
> this member to const char*.
> 
> 
> Best regards,
> Victor
> 
> -- 
> GNU/Linux user #446397 - http://counter.li.org
> >
-------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/>
_______________________________________________
> Cunit-development mailing list
> Cun...@li...
> https://lists.sourceforge.net/lists/listinfo/cunit-development
> 



      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ 

[Cunit-development] CU_TestInfo and CU_SuiteInfo with char*

[Victor M. O. <rha...@gm...>]

Hi,

I'm using CUnit in my company to automate the unit tests for our systems.
I was writing my tests code when I got this error:
"unit_test.h:81: warning: initialization discards qualifiers from pointer
target type"
The warning level is a standard of my company too.

I'm writing my code like your document explain:
CU_SuiteInfo suites[] = {
  {
      "Application Core Tests",
      app_core_test_suite_init_func,
      app_core_test_suite_cleanup_func,
      app_core_tests
  },
And so on.

So a ask you:
Is there a reason for CU_TestInfo and CU_SuiteInfo has pName member as char*
instead const char*?

At my first look at your source code, I didn't see no problems to change
this member to const char*.


Best regards,
Victor

-- 
GNU/Linux user #446397 - http://counter.li.org

[Cunit-development] Patch to fix CU_basic_run_suite and CU_basic_run_test

[John P. <jo...@cu...>]

Hi all

I submitted a patch to fix a simple bug in CUnit. It's available via the
CUnit SF.net project page.

Is there any chance this patch could be incorporated soon into a new
release?

Also, there was a post here recently on ways to run specific CUnit tests
from the command line. I have some code that achieves this, see here if
you're interested:
http://ascendcode.cheme.cmu.edu/viewvc.cgi/code/branches/extfn/base/generic/test/test.c?view=markup

Using the above I can do

./test ?
./test TestSuiteName
./test TestSuiteName.?
./test TestSuiteName.TestCaseName

The '?' cases output a list of possible test suites and/or test names.
It's not particular fantastic but it works (but depends on the
abovementioned patch).

Cheers
JP

[Cunit-development] Thoughts about this?

[Tennis S. <ten...@ya...>]

Hi,

 

In my own copy of CUnit, I'm making modifications to print the suite/test
numbers as well as the names. I'm doing this to provide a kind of shorthand
to identify tests and call them on-demand from the command line.

 

For example, 

Suite: FDT
Test: DFFDTCreate ... passed
Test: DFFDTParse1 ... passed
Test: DFFDTParse2 ... passed
Suite: SDP
Test: DFSDPCreateSession ... passed
Test: DFSDPCreateSession null pointer ... passed
Test: DFSDPParse sample 1 ... passed

Would now print something like this:

Suite 1: FDT
Test 1: DFFDTCreate ... passed
Test 2: DFFDTParse1 ... passed
Test 3: DFFDTParse2 ... passed
Suite 2: SDP
Test 1: DFSDPCreateSession ... passed
Test 2: DFSDPCreateSession null pointer ... passed
Test 3: DFSDPParse sample 1 ... passed

With this, I'll be adding a cli option to pass numbers for suite/test
combinations.  For example "FDT.DFFTParse1" would be called as "1/2".

Does anyone have anything similar to this already? If not, would you be
interested in adding it to the utility permanently?

Thanks,

-Tennis

[Cunit-development] Anyone Have This ... ??

[Tennis S. <te...@di...>]

Hi,

 

Has anyone written any extensions to CUnit that will run tests based on
parms passed in an input file?  Also, are there any examples out there of
dynamic creation/modification of large numbers of suites and tests? 

 

Thanks,

-T

[Cunit-development] Newbie: link error linking test program with CUnit (Windows)

[Dhananjay M. <ma...@se...>]

All,

I am writing a simple test using libcunit on Windows XP (SP2) with Visual
studio .Net 2003 version. When I compile the test with "cl .... /MD" option
and link with "link .... /NODEFAULTLIB:LIBC", I get linker errors (see
below). This is due to isspace() in _CU_trim_left routine in Util.c. 

Now for me to test my code using cunit I *have* to use "/MD" and
"NODEFAULTLIB:LIBC" options as all my DLLs are linked that way. 

Is there any workaround? I really would like to use CUnit for unit testing. 
But with this I am stuck. 

Thanks in advance,
-Jay
PS: Please cc me on replies as I am not subscribed.

Compile output:

cl /c commontest.c /I c:/work/Base/tests/ext/CUnit/
Headers /INCREMENTAL:NO /DEBUG /MD
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86
Copyright (C) Microsoft Corporation 1984-2002. All rights reserved.

commontest.c
link commontest.obj /OUT:c:/work/Base/tests/bin/commontest.exe /NOLOGO
/DEBUG /LIBPATH:c:/work/Base/tests/ext/CUnit/lib /DEFAULTLIB:libcunit
/NODEFAULTLIB:LIBC
libcunit.lib(Util.obj) : error LNK2001: unresolved external symbol __pctype
libcunit.lib(Util.obj) : error LNK2001: unresolved external symbol
___mb_cur_max

c:/work/Base/tests/bin/commontest.exe : fatal error LNK1120: 2 unresolved
externals