moparisthebest/curl
1
0
Fork 0
mirror of https://github.com/moparisthebest/curl synced 2024-11-17 15:05:02 -05:00
Code Issues Releases Wiki Activity
9d964e5477
curl/tests/unit/Makefile.inc

59 lines
1.7 KiB
PHP
Raw Normal View History

unittest: framework for unit-testing This is the first approach at doing fairly clean and easy to write and debug unit tests.
2011-01-01 11:33:42 -05:00
# these files are used in every single unit test program
unit tests: build adjustment Also define UNITTESTS macro when building unit test sources. Fixing compiler warning: external definition with no prior declaration
2011-05-25 14:22:46 -04:00
UNITFILES = curlcheck.h \
Makefile.inc: fix $(top_srcdir) not allowed in _SOURCES variables
2013-01-19 22:17:11 -05:00
../libtest/test.h \
../libtest/first.c
unittest: framework for unit-testing This is the first approach at doing fairly clean and easy to write and debug unit tests.
2011-01-01 11:33:42 -05:00
# These are all unit test programs
unit test formpost: added test case 1308 This is a few first rather basic tests of curl_formadd() and curl_formget(). Should serve as building blocks to add more variations to the test.
2011-06-10 06:03:29 -04:00
UNITPROGS = unit1300 unit1301 unit1302 unit1303 unit1304 unit1305 unit1307 \
mprintf: allow %.s with data not being zero terminated If the precision is indeed shorter than the string, don't strlen() to find the end because that's not how the precision operator works. I also added a unit test for curl_msnprintf to make sure this works and that the fix doesn't a few other basic use cases. I found a POSIX compliance problem that I marked TODO in the unit test, and I figure we need to add more tests in the future. Reported-by: Török Edwin
2014-05-04 17:37:24 -04:00
unit1308 unit1309 unit1330 unit1394 unit1395 unit1396 unit1397 unit1398
unittest: framework for unit-testing This is the first approach at doing fairly clean and easy to write and debug unit tests.
2011-01-01 11:33:42 -05:00
unit1300_SOURCES = unit1300.c $(UNITFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
unit1300_CPPFLAGS = $(AM_CPPFLAGS)
unittest: verify curl_strequal
2011-01-04 10:13:58 -05:00
unit1301_SOURCES = unit1301.c $(UNITFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
unit1301_CPPFLAGS = $(AM_CPPFLAGS)
unittest: test base64 encode/decode
2011-01-04 10:42:31 -05:00
unit1302_SOURCES = unit1302.c $(UNITFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
unit1302_CPPFLAGS = $(AM_CPPFLAGS)
unittest: 1303 tests Curl_timeleft I came up with 33 different ways to call it and verify that it returns the correct return code.
2011-01-04 17:10:45 -05:00
unit1303_SOURCES = unit1303.c $(UNITFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
unit1303_CPPFLAGS = $(AM_CPPFLAGS)
test1304: Added some unit tests for Curl_parsenetrc. Moved some definitons into the header file so that we can reuse them.
2011-02-08 01:12:37 -05:00
unit1304_SOURCES = unit1304.c $(UNITFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
unit1304_CPPFLAGS = $(AM_CPPFLAGS)
Converted tests 558 & 559 to use the unit test framework as 1305 Test 558 was just a subset of 559 which is something that can be easily added later.
2011-03-04 17:32:58 -05:00
unit1305_SOURCES = unit1305.c $(UNITFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
unit1305_CPPFLAGS = $(AM_CPPFLAGS)
Moved test 577 into the unit test framework as test 1307
2011-03-04 18:56:40 -05:00
unit1307_SOURCES = unit1307.c $(UNITFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
unit1307_CPPFLAGS = $(AM_CPPFLAGS)
unit test formpost: added test case 1308 This is a few first rather basic tests of curl_formadd() and curl_formget(). Should serve as building blocks to add more variations to the test.
2011-06-10 06:03:29 -04:00
unit1308_SOURCES = unit1308.c $(UNITFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
unit1308_CPPFLAGS = $(AM_CPPFLAGS)
splay: add unit tests The test code that was #ifdef'ed in the code was converted into unit tests in test case 1309. I also removed the #if 0'ed code from splay.c
2011-06-10 14:19:35 -04:00
unit1309_SOURCES = unit1309.c $(UNITFILES)
build: use per-target '_CPPFLAGS' for those currently using default Automake documents that doing this will make it choose a different name for intermediate object files even when sharing source files across targets of same Makefile.am. Up to automake 1.13.1 target's intermediate object files were placed in the build subdirectory of the target. We depended on this, probably undocumented behavior, to achieve same behavior as if a per-target flag had been specified when building targets that actually belong to different Makefile.am files. It seems automake 1.13.2 is going to break behavior mentioned above. So, lets use a documented behavior in order to achieve same purpose, across automake versions, no matter where automake wishes to place intermediate object files. Our build targets that already were using a per-target '_CFLAGS' or '_CPPFLAGS' need no 'fixing', these were already 'fixed'. The only Makefile.am or Makefile.in files in libcurl's source tree touched by this 'fix' are tests/libtest/Makefile.inc and tests/unit/Makefile.inc.
2013-01-15 10:28:07 -05:00
unit1309_CPPFLAGS = $(AM_CPPFLAGS)
tests: add #96 #558 and #1330 These verfy that the 'memory tracking' subsystem is actually doing its job when using curl tool (#96), a test in libtest (#558) and also a unit test (#1330), in order to prevent regressions in this functionallity.
2013-03-15 14:58:00 -04:00
unit1330_SOURCES = unit1330.c $(UNITFILES)
unit1330_CPPFLAGS = $(AM_CPPFLAGS)
unit1394.c: plug the curl tool unit test in
2013-05-03 07:26:25 -04:00
unit1394_SOURCES = unit1394.c $(UNITFILES)
build: fixed unit1394 for debug and metlink builds
2013-05-06 17:28:04 -04:00
unit1394_CPPFLAGS = $(AM_CPPFLAGS) $(LIBMETALINK_CPPFLAGS)
unit1394_LDADD = @LIBMETALINK_LIBS@ $(top_builddir)/lib/libcurl.la @LIBCURL_LIBS@
unit1394_LDFLAGS = @LIBMETALINK_LDFLAGS@ $(top_builddir)/src/libcurltool.la
unit1394_LIBS =
unit1396: unit tests to verify curl_easy_(un)escape
2013-05-19 17:30:06 -04:00
dotdot: introducing dot file path cleanup RFC3986 details how a path part passed in as part of a URI should be "cleaned" from dot sequences before getting used. The described algorithm is now implemented in lib/dotdot.c with the accompanied test case in test 1395. Bug: http://curl.haxx.se/bug/view.cgi?id=1200 Reported-by: Alex Vinnik
2013-06-15 17:47:02 -04:00
unit1395_SOURCES = unit1395.c $(UNITFILES)
unit1395_CPPFLAGS = $(AM_CPPFLAGS)
unit1396: unit tests to verify curl_easy_(un)escape
2013-05-19 17:30:06 -04:00
unit1396_SOURCES = unit1396.c $(UNITFILES)
unit1396_CPPFLAGS = $(AM_CPPFLAGS)
test1397: unit test for certificate name wildcard handling
2014-02-22 10:52:58 -05:00
unit1397_SOURCES = unit1397.c $(UNITFILES)
unit1397_CPPFLAGS = $(AM_CPPFLAGS)
mprintf: allow %.s with data not being zero terminated If the precision is indeed shorter than the string, don't strlen() to find the end because that's not how the precision operator works. I also added a unit test for curl_msnprintf to make sure this works and that the fix doesn't a few other basic use cases. I found a POSIX compliance problem that I marked TODO in the unit test, and I figure we need to add more tests in the future. Reported-by: Török Edwin
2014-05-04 17:37:24 -04:00
unit1398_SOURCES = unit1398.c $(UNITFILES)
unit1398_CPPFLAGS = $(AM_CPPFLAGS)
Reference in New Issue Copy Permalink