-
Notifications
You must be signed in to change notification settings - Fork 11.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[ROCKETMQ-264]Fix unit test cost too long and exception in unit test #145
Conversation
1 similar comment
new MessageStoreConfig()); | ||
assertThat(brokerController.initialize()); | ||
brokerController.start(); | ||
brokerController.shutdown(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we only start/shutdown broker once, testBrokerRestart
isn't a appropriate method~
e.printStackTrace(); | ||
assertThat(true).isFalse(); | ||
} | ||
Thread.sleep(200); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is 200ms
enough to dispatch consume queue in a slow speed disk, or do we have another method to ensure the CQ has been constructed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At this time,there is no way to ensure CQ constructed except adding countdownlatch to CQ,if only in test,I think there is no need to do this.
int queueSize = new Random().nextInt(100)+1;//1-100 | ||
testAllocate(queueSize,consumerSize); | ||
public void testRun100RandomCase() { | ||
for (int i = 0; i < 10; i++) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Method name should be polish~
try { | ||
Thread.sleep(1); | ||
} catch (InterruptedException e) {} | ||
} catch (InterruptedException e) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add exception to method signature is better~
try { | ||
master = gen(filterManager); | ||
} catch (Exception e) { | ||
e.printStackTrace(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
redundant code, when you use assert in your exception scenario, right ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep,that's a good idea and this exception will be fixed at next commit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a DefaultMessageStore start progress that used in annotation Before.And can't add expect Exception in before,I think there is no need to add exception expect in before and all we want is while the messageStore is started or not.
brokerController.start(); | ||
brokerController.shutdown(); | ||
} | ||
BrokerController brokerController = new BrokerController( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By changing this you change the expected behavior -- it is a check for proper restart
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As there is more whole startup in test case , I think there no need to do this. Any questions?IMO
@@ -1,46 +0,0 @@ | |||
/* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is it deleted??
int consumerSize = new Random().nextInt(200) + 1;//1-200 | ||
int queueSize = new Random().nextInt(100) + 1;//1-100 | ||
for (int i = 0; i < 10; i++) { | ||
int consumerSize = new Random().nextInt(20) + 1;//1-20 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Guys, what's the point to reduce these numbers (in other tests in this PR too)?
@vongosling @zhouxinyu
IMO, we need to have a pretty high number for messages/queues/etc. in unit tests, because it is a large-scale messaging system. Unless it makes tests really slow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@shroman I would like to verify the program correction though the specific trick not iteration count(such as mock) especially in unit-test, while you mentioned "have a pretty high number for messages/queues/etc", IMO, we can do it in integration test. thoughts ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@vongosling If you have stress tests for this, I think low numbers here are ok.
Btw, how do/will you verify it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@shroman we can talk about these problems in dev mail. How to unit test, integration-test, performance test and stress test, and what's the main goal when we do it :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it spend too much time to allocate queue ? If not, i think it does't matter to run 10 or 100 times.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We aim at making test cost less time, make iteration count less is a good idea as unit test is only test for function.
} | ||
//wait for consume queue build | ||
Thread.sleep(100); | ||
Thread.sleep(10); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is 10ms enough to build consume queue?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In test scenario, 10ms is enough.
} | ||
|
||
@After | ||
public void destory() { | ||
messageStore.shutdown(); | ||
messageStore.destroy(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As i remember, method of destroy may not clean all files generated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Delete created files has been did before at this file after destroy.
int consumerSize = new Random().nextInt(200) + 1;//1-200 | ||
int queueSize = new Random().nextInt(100) + 1;//1-100 | ||
for (int i = 0; i < 10; i++) { | ||
int consumerSize = new Random().nextInt(20) + 1;//1-20 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it spend too much time to allocate queue ? If not, i think it does't matter to run 10 or 100 times.
} | ||
//wait for consume queue build | ||
Thread.sleep(100); | ||
Thread.sleep(10); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it enough to build consume queue ?
@lindzh Thanks, I made some modifications and merged this PR. You could close it :-) |
When run mvn test , it cost too much time and some times there is exception in unit test and the test result is pass
JIRA ticket https://issues.apache.org/jira/browse/ROCKETMQ-264