db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Øystein Grøvlen (JIRA) <j...@apache.org>
Subject [jira] Updated: (DERBY-3162) Create a framework for replication tests
Date Fri, 07 Mar 2008 17:15:46 GMT

     [ https://issues.apache.org/jira/browse/DERBY-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Ø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

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.

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)

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

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

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

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

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

 * 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.

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

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

 * I suggest using assertSQLState to check that the expected exception

> 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