db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ole Solberg (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3162) Create a framework for replication tests
Date Fri, 07 Mar 2008 18:49:48 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12576322#action_12576322

Ole Solberg commented on DERBY-3162:

Thanks Øystein, for your comments and committing the patch!

> Øystein Grøvlen updated DERBY-3162:
> -----------------------------------
>     Derby Info:   (was: [Patch Available])
> Thanks for the new tests, Ole.  I have committed the derby-3162.3-v4d.diff.txt patch
as revision 634734.
> I think there is quite a few things that needs to be cleaned up, but I am still committing
this as I think  the tests are useful, and I have checked that it does not break the regression
tests.  I have not have time to verify that all state changes are covered, and I hope that
other people could join in verifying this.

There is definitly quite some cleanup that needs to be done on theses tests and framework.
Your comments are all valid and useful!

> Some initial comments/questions:
>  * When I run the junit regression test, I get the directories from
>    the replication tests in the current directory.  Most tests write
>    to the system directory.  (I know this is not the only test that
>    violates this)

I will fix this.

>  * Why is not the replication suite put in the suites package like all
>    other suites?

I will fix this.

>  * What would it take to run the replication tests with the security
>    manager? 

I must admit I have to investigate that.

>  * I would prefer if the tests were given more meaningful names?
>    part1a and part1b does not tell me very much what has been tested.

I agree.

>  * Why is there only one test case per class?  Would it not make sense
>    to put all state tests into the same class?

I think that should be done.

>  * Why has not part2 of the stat tests been added to the test suite?

But I think it is:
>From ReplicationSuite:

>  * I had hoped that the same test classes could be used both for running
>    locally and distributed, and that a property/parameter was used to
>    determine how to run it.  How much work will it be to enable that.

That is he intention. The framework and tests were initially written for and run
in a distributed context.

This patch has only been tested for running locally, and was specifically
meant to be useable for running the replication tests as part of suites.All.

For the distributed case the selection of server hosts, test to run etc. 
are specified in a property file.
There should not be much work to (re)enable that.

>  * What is the purpose of testReplication_CleanUp?  It seems to only
>    stop servers.

It is currently not used, should be removed.

>  * All the methods with multiple parameters that all uses defaults,
>    makes the tests less readable.

I agree.

>  * I suggest using assertSQLState to check that the expected exception
>    occurs.

I will change to that - I actually knew it were available so I should have used it!

> Create a framework for replication tests
> ----------------------------------------
>                 Key: DERBY-3162
>                 URL: https://issues.apache.org/jira/browse/DERBY-3162
>             Project: Derby
>          Issue Type: Sub-task
>          Components: Test
>    Affects Versions:
>            Reporter: Ole Solberg
>            Assignee: Ole Solberg
>            Priority: Minor
>         Attachments: derby-3162.1-v1.diff.txt, derby-3162.2-v2.diff.txt, derby-3162.2-v2.stat.txt,
derby-3162.3-v1.diff.txt, derby-3162.3-v1.stat.txt, derby-3162.3-v2.diff.txt, derby-3162.3-v2.stat.txt,
derby-3162.3-v3.diff.txt, derby-3162.3-v3.stat.txt, derby-3162.3-v4c.diff.txt, derby-3162.3-v4c.stat.txt,
derby-3162.3-v4d.diff.txt, derby-3162.3-v4d.stat.txt
> Handle
>  - starting and stopping Derby servers to have the master and slave replication roles,
>  - doing administrative commands like startreplication, startslave, stopreplication,
>  - performing consistency checks on the slave vs. the master,
>  - running load clients against master and slave in the various states of replication,
>  - provoking error situations on master and slave, and network,
>  - ... 

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message