Re: [PATCH v3] Isolate If-Modified-Since handling in gitweb

Jakub Narebski [off-list ref] writes:

quoted

1: tests for i-m-s and git_feed
2: refactor i-m-s handling

Those two can be in single commit.  Tests added need only test i-m-s
using git_feed ('atom' or 'rss' action), as it is the only user,
and you touch only i-m-s handling.

Correct.

quoted

3: tests for i-m-s and git_snapshot (which fail until 4)
4: add i-m-s to git_snapshot

We usually put tests together with feature.  Tests before feature means
that you would need to mark them as test_expect_failure, as they would
not pass before feature is added, isn't it?

Correct.

In a more elaborate series, you would first add a lot of tests to nail the
behaviour of the existing code down, then refactor or reimplement them in
a different way, add tests that expect failure until the next phase, and
then add features and turn expect_failure in tests to expect_success.

But I do not htink this single patch deserves that complexity.  Does it
even have to split into three?

On Wed, Mar 21, 2012 at 01:09:24PM -0700, Junio C Hamano wrote:

In a more elaborate series, you would first add a lot of tests to nail the
behaviour of the existing code down, then refactor or reimplement them in
a different way, add tests that expect failure until the next phase, and
then add features and turn expect_failure in tests to expect_success.

But I do not htink this single patch deserves that complexity.  Does it
even have to split into three?

Sorry, testing makes me think of test-driven development ;).  Two
patches it is (refactor + git_feed tests, git_snapshot + git_snapshot
tests).

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy