1
0
Fork 0
mirror of https://github.com/git/git.git synced 2024-11-14 21:23:03 +01:00
Commit graph

6 commits

Author SHA1 Message Date
René Scharfe
ee1431bfc5 MALLOC_CHECK: enable it, unless disabled explicitly
The malloc checks in tests are currently disabled.  Actually evaluate
the variable for turning them off and enable them if it's unset.

Also use this opportunity to give it the more descriptive and
consistent name TEST_NO_MALLOC_CHECK.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-26 23:39:13 -07:00
Junio C Hamano
1b3185fc2b MALLOC_CHECK: various clean-ups
The most important in this change is to avoid affecting anything
when test-lib is used from perf-lib.  It also limits the effect of
the MALLOC_CHECK only to what is run inside the actual test, and
uses a fixed MALLOC_PERTURB_ in order to avoid hurting repeatability
of the tests.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-09-17 22:00:27 -07:00
Michał Kiedrowicz
d17cf5f3a3 tests: Introduce test_seq
Jeff King wrote:

	The seq command is GNU-ism, and is missing at least in older BSD
	releases and their derivatives, not to mention antique
	commercial Unixes.

	We already purged it in b3431bc (Don't use seq in tests, not
	everyone has it, 2007-05-02), but a few new instances have crept
	in. They went unnoticed because they are in scripts that are not
	run by default.

Replace them with test_seq that is implemented with a Perl snippet
(proposed by Jeff).  This is better than inlining this snippet
everywhere it's needed because it's easier to read and it's easier
to change the implementation (e.g. to C) if we ever decide to remove
Perl from the test suite.

Note that test_seq is not a complete replacement for seq(1).  It
just has what we need now, in addition that it makes it possible for
us to do something like "test_seq a m" if we wanted to in the
future.

There are also many places that do `for i in 1 2 3 ...` but I'm not sure
if it's worth converting them to test_seq.  That would introduce running
more processes of Perl.

Signed-off-by: Michał Kiedrowicz <michal.kiedrowicz@gmail.com>
Acked-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-04 16:06:07 -07:00
Thomas Rast
561ae06735 perf: export some important test-lib variables
The only bug right now is that $GIT_TEST_CMP is needed for test_cmp to
work.

However, we also export the three most important paths for tests:

  TEST_DIRECTORY
  TRASH_DIRECTORY
  GIT_BUILD_DIR

Since they are available within test_expect_success, a future test
writer may expect them to also be defined in test_perf.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-08 12:07:50 -08:00
Thomas Rast
1cbc32403b perf: load test-lib-functions from the correct directory
Loading it in the subshells still referred to $TEST_DIRECTORY/..,
which was only correct in preliminary versions of perf-lib.sh

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-03-08 11:38:09 -08:00
Thomas Rast
342e9ef2d9 Introduce a performance testing framework
This introduces a performance testing framework under t/perf/.  It
tries to be as close to the test-lib.sh infrastructure as possible,
and thus should be easy to get used to for git developers.

The following points were considered for the implementation:

1. You usually want to compare arbitrary revisions/build trees against
   each other.  They may not have the performance test under
   consideration, or even the perf-lib.sh infrastructure.

   To cope with this, the 'run' script lets you specify arbitrary
   build dirs and revisions.  It even automatically builds the revisions
   if it doesn't have them at hand yet.

2. Usually you would not want to run all tests.  It would take too
   long anyway.  The 'run' script lets you specify which tests to run;
   or you can also do it manually.  There is a Makefile for
   discoverability and 'make clean', but it is not meant for
   real-world use.

3. Creating test repos from scratch in every test is extremely
   time-consuming, and shipping or downloading such large/weird repos
   is out of the question.

   We leave this decision to the user.  Two different sizes of test
   repos can be configured, and the scripts just copy one or more of
   those (using hardlinks for the object store).  By default it tries
   to use the build tree's git.git repository.

   This is fairly fast and versatile.  Using a copy instead of a clone
   preserves many properties that the user may want to test for, such
   as lots of loose objects, unpacked refs, etc.

Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-02-17 08:21:22 -08:00