git/t
Junio C Hamano f7c1512af8 [PATCH] Rename/copy detection fix.
The rename/copy detection logic in earlier round was only good
enough to show patch output and discussion on the mailing list
about the diff-raw format updates revealed many problems with
it.  This patch fixes all the ones known to me, without making
things I want to do later impossible, mostly related to patch
reordering.

 (1) Earlier rename/copy detector determined which one is rename
     and which one is copy too early, which made it impossible
     to later introduce diffcore transformers to reorder
     patches.  This patch fixes it by moving that logic to the
     very end of the processing.

 (2) Earlier output routine diff_flush() was pruning all the
     "no-change" entries indiscriminatingly.  This was done due
     to my false assumption that one of the requirements in the
     diff-raw output was not to show such an entry (which
     resulted in my incorrect comment about "diff-helper never
     being able to be equivalent to built-in diff driver").  My
     special thanks go to Linus for correcting me about this.
     When we produce diff-raw output, for the downstream to be
     able to tell renames from copies, sometimes it _is_
     necessary to output "no-change" entries, and this patch
     adds diffcore_prune() function for doing it.

 (3) Earlier diff_filepair structure was trying to be not too
     specific about rename/copy operations, but the purpose of
     the structure was to record one or two paths, which _was_
     indeed about rename/copy.  This patch discards xfrm_msg
     field which was trying to be generic for this wrong reason,
     and introduces a couple of fields (rename_score and
     rename_rank) that are explicitly specific to rename/copy
     logic.  One thing to note is that the information in a
     single diff_filepair structure _still_ does not distinguish
     renames from copies, and it is deliberately so.  This is to
     allow patches to be reordered in later stages.

 (4) This patch also adds some tests about diff-raw format
     output and makes sure that necessary "no-change" entries
     appear on the output.

Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-05-23 11:49:30 -07:00
..
lib-read-tree-m-3way.sh [PATCH] Add tests for diff-tree 2005-05-20 09:27:43 -07:00
Makefile t/Makefile: OPTS -> GIT_TEST_OPTS 2005-05-14 17:58:22 +02:00
README [PATCH 4/4] Trivial test harness fixes. 2005-05-16 00:22:10 +02:00
t0000-basic.sh [PATCH] The diff-raw format updates. 2005-05-21 22:49:19 -07:00
t0100-environment-names.sh [PATCH 2/2] The core GIT tests: recent additions and fixes. 2005-05-14 17:41:01 +02:00
t0110-environment-names-old.sh Fix up previous commit 2005-05-19 22:39:27 -07:00
t1000-read-tree-m-3way.sh [PATCH] Add tests for diff-tree 2005-05-20 09:27:43 -07:00
t2000-checkout-cache-clash.sh Rename some test scripts and describe the naming convention 2005-05-15 01:34:22 +02:00
t2001-checkout-cache-clash.sh Rename some test scripts and describe the naming convention 2005-05-15 01:34:22 +02:00
t2002-checkout-cache-u.sh Fix up previous commit 2005-05-19 22:39:27 -07:00
t2100-update-cache-badpath.sh Fixed misnamed t/t2010-update-cache-badpath.sh 2005-05-15 01:42:31 +02:00
t3000-ls-files-others.sh Rename some test scripts and describe the naming convention 2005-05-15 01:34:22 +02:00
t3010-ls-files-killed.sh Rename some test scripts and describe the naming convention 2005-05-15 01:34:22 +02:00
t4000-diff-format.sh Fix up previous commit 2005-05-19 22:39:27 -07:00
t4001-diff-rename.sh [PATCH] Diff overhaul, adding half of copy detection. 2005-05-21 09:58:03 -07:00
t4002-diff-basic.sh [PATCH] The diff-raw format updates. 2005-05-21 22:49:19 -07:00
t4003-diff-rename-1.sh [PATCH] Rename/copy detection fix. 2005-05-23 11:49:30 -07:00
t4004-diff-rename-symlink.sh [PATCH] Be careful with symlinks when detecting renames and copies. 2005-05-23 11:49:30 -07:00
t4005-diff-rename-2.sh [PATCH] Rename/copy detection fix. 2005-05-23 11:49:30 -07:00
test-lib.sh [PATCH 1/2] Test suite fixup. 2005-05-14 18:06:21 +02:00

Core GIT Tests
==============

This directory holds many test scripts for core GIT tools.  The
first part of this short document describes how to run the tests
and read their output.

When fixing the tools or adding enhancements, you are strongly
encouraged to add tests in this directory to cover what you are
trying to fix or enhance.  The later part of this short document
describes how your test scripts should be organized.


Running Tests
-------------

The easiest way to run tests is to say "make".  This runs all
the tests.

    *** t0000-basic.sh ***
    *   ok 1: .git/objects should be empty after git-init-db in an empty repo.
    *   ok 2: .git/objects should have 256 subdirectories.
    *   ok 3: git-update-cache without --add should fail adding.
    ...
    *   ok 23: no diff after checkout and git-update-cache --refresh.
    * passed all 23 test(s)
    *** t0100-environment-names.sh ***
    *   ok 1: using old names should issue warnings.
    *   ok 2: using old names but having new names should not issue warnings.
    ...

Or you can run each test individually from command line, like
this:

    $ sh ./t3001-ls-files-killed.sh
    *   ok 1: git-update-cache --add to add various paths.
    *   ok 2: git-ls-files -k to show killed files.
    *   ok 3: validate git-ls-files -k output.
    * passed all 3 test(s)

You can pass --verbose (or -v), --debug (or -d), and --immediate
(or -i) command line argument to the test.

--verbose::
	This makes the test more verbose.  Specifically, the
	command being run and their output if any are also
	output.

--debug::
	This may help the person who is developing a new test.
	It causes the command defined with test_debug to run.

--immediate::
	This causes the test to immediately exit upon the first
	failed test.


Naming Tests
------------

The test files are named as:

	tNNNN-commandname-details.sh

where N is a decimal digit.

First digit tells the family:

	0 - the absolute basics and global stuff
	1 - the basic commands concerning database
	2 - the basic commands concerning the working tree
	3 - the other basic commands (e.g. ls-files)
	4 - the diff commands
	5 - the pull and exporting commands
	6 - the revision tree commands (even e.g. merge-base)

Second digit tells the particular command we are testing.

Third digit (optionally) tells the particular switch or group of switches
we are testing.


Writing Tests
-------------

The test script is written as a shell script.  It should start
with the standard "#!/bin/sh" with copyright notices, and an
assignment to variable 'test_description', like this:

	#!/bin/sh
	#
	# Copyright (c) 2005 Junio C Hamano
	#

	test_description='xxx test (option --frotz)

	This test registers the following structure in the cache
	and tries to run git-ls-files with option --frotz.'


Source 'test-lib.sh'
--------------------

After assigning test_description, the test script should source
test-lib.sh like this:

	. ./test-lib.sh

This test harness library does the following things:

 - If the script is invoked with command line argument --help
   (or -h), it shows the test_description and exits.

 - Creates an empty test directory with an empty .git/objects
   database and chdir(2) into it.  This directory is 't/trash'
   if you must know, but I do not think you care.

 - Defines standard test helper functions for your scripts to
   use.  These functions are designed to make all scripts behave
   consistently when command line arguments --verbose (or -v),
   --debug (or -d), and --immediate (or -i) is given.


End with test_done
------------------

Your script will be a sequence of tests, using helper functions
from the test harness library.  At the end of the script, call
'test_done'.


Test harness library
--------------------

There are a handful helper functions defined in the test harness
library for your script to use.

 - test_expect_success <message> <script>

   This takes two strings as parameter, and evaluates the
   <script>.  If it yields success, test is considered
   successful.  <message> should state what it is testing.

   Example:

	test_expect_success \
	    'git-write-tree should be able to write an empty tree.' \
	    'tree=$(git-write-tree)'

 - test_expect_failure <message> <script>

   This is the opposite of test_expect_success.  If <script>
   yields success, test is considered a failure.

   Example:

	test_expect_failure \
	    'git-update-cache without --add should fail adding.' \
	    'git-update-cache should-be-empty'

 - test_debug <script>

   This takes a single argument, <script>, and evaluates it only
   when the test script is started with --debug command line
   argument.  This is primarily meant for use during the
   development of a new test script.

 - test_done

   Your test script must have test_done at the end.  Its purpose
   is to summarize successes and failures in the test script and
   exit with an appropriate error code.


Tips for Writing Tests
----------------------

As with any programming projects, existing programs are the best
source of the information.  However, do _not_ emulate
t0000-basic.sh when writing your tests.  The test is special in
that it tries to validate the very core of GIT.  For example, it
knows that there will be 256 subdirectories under .git/objects/,
and it knows that the object ID of an empty tree is a certain
40-byte string.  This is deliberately done so in t0000-basic.sh
because the things the very basic core test tries to achieve is
to serve as a basis for people who are changing the GIT internal
drastically.  For these people, after making certain changes,
not seeing failures from the basic test _is_ a failure.  And
such drastic changes to the core GIT that even changes these
otherwise supposedly stable object IDs should be accompanied by
an update to t0000-basic.sh.

However, other tests that simply rely on basic parts of the core
GIT working properly should not have that level of intimate
knowledge of the core GIT internals.  If all the test scripts
hardcoded the object IDs like t0000-basic.sh does, that defeats
the purpose of t0000-basic.sh, which is to isolate that level of
validation in one place.  Your test also ends up needing
updating when such a change to the internal happens, so do _not_
do it and leave the low level of validation to t0000-basic.sh.