Jakub Narebski <jnareb@xxxxxxxxx> writes:
>> 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.
>> 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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html