You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Paul Burba <pt...@gmail.com> on 2010/05/26 18:17:02 UTC
Breaking merge_tests.py into 3 parts
Frequently I want to test just the subset of merge_tests.py related to
--reintegrate as a quick sanity check during development for that
feature. To make this a bit easier I'd like to break merge_tests.py
into three separate tests:
1) merge_reintegrate_tests.py - All merge --reintegrate tests
2) merge_tree_conflicts_tests.py - All merge tests related to tree-conflicts
3) merge_tests.py - Everything that doesn't fit in the other two
Any objections?
Paul
Re: Breaking merge_tests.py into 3 parts
Posted by Paul Burba <pt...@gmail.com>.
On Wed, May 26, 2010 at 3:45 PM, Stefan Sperling <st...@elego.de> wrote:
> On Wed, May 26, 2010 at 01:42:38PM -0500, Hyrum K. Wright wrote:
>> The common complaint is that by renumbering the tests, we break historical
>> comments such as "fixes bar_test FOO". But those comments are often
>> versioned, so a little archaeology can divine the answer. I don't think
>> such concerns should keep us from moving forward in the test suite.
>
> Also, for some time now we've had support to run python tests by passing
> the function name as an argument, rather than passing a test number.
> So we could encourage people to refer to python tests using their function
> names. That would avoid such problems.
> Unfortunately this does not work for C tests...
>
> Back on topic: I don't see a problem with splitting up the merge tests.
>
> Stefan
Done, http://svn.apache.org/viewvc?view=revision&revision=948873
Paul
Re: Breaking merge_tests.py into 3 parts
Posted by Stefan Sperling <st...@elego.de>.
On Wed, May 26, 2010 at 01:42:38PM -0500, Hyrum K. Wright wrote:
> The common complaint is that by renumbering the tests, we break historical
> comments such as "fixes bar_test FOO". But those comments are often
> versioned, so a little archaeology can divine the answer. I don't think
> such concerns should keep us from moving forward in the test suite.
Also, for some time now we've had support to run python tests by passing
the function name as an argument, rather than passing a test number.
So we could encourage people to refer to python tests using their function
names. That would avoid such problems.
Unfortunately this does not work for C tests...
Back on topic: I don't see a problem with splitting up the merge tests.
Stefan
Re: Breaking merge_tests.py into 3 parts
Posted by "Hyrum K. Wright" <hy...@mail.utexas.edu>.
On Wed, May 26, 2010 at 1:17 PM, Paul Burba <pt...@gmail.com> wrote:
> Frequently I want to test just the subset of merge_tests.py related to
> --reintegrate as a quick sanity check during development for that
> feature. To make this a bit easier I'd like to break merge_tests.py
> into three separate tests:
>
> 1) merge_reintegrate_tests.py - All merge --reintegrate tests
>
> 2) merge_tree_conflicts_tests.py - All merge tests related to
> tree-conflicts
>
> 3) merge_tests.py - Everything that doesn't fit in the other two
>
+1 This has been a long time in coming.
The common complaint is that by renumbering the tests, we break historical
comments such as "fixes bar_test FOO". But those comments are often
versioned, so a little archaeology can divine the answer. I don't think
such concerns should keep us from moving forward in the test suite.
-Hyrum
Re: Breaking merge_tests.py into 3 parts
Posted by "C. Michael Pilato" <cm...@collab.net>.
Paul Burba wrote:
> Frequently I want to test just the subset of merge_tests.py related to
> --reintegrate as a quick sanity check during development for that
> feature. To make this a bit easier I'd like to break merge_tests.py
> into three separate tests:
>
> 1) merge_reintegrate_tests.py - All merge --reintegrate tests
>
> 2) merge_tree_conflicts_tests.py - All merge tests related to tree-conflicts
>
> 3) merge_tests.py - Everything that doesn't fit in the other two
>
> Any objections?
+145 ;-)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand