Skip to content
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

Closed
wants to merge 8 commits into from

Conversation

lindzh
Copy link
Contributor

@lindzh lindzh commented Aug 11, 2017

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

@lindzh lindzh changed the base branch from master to develop August 11, 2017 09:44
@lindzh lindzh changed the title [ROCKETMQ-264] Fix unit test cost too long and exception in unit test [ROCKETMQ-264]Fix unit test cost too long and exception in unit test Aug 11, 2017
@coveralls
Copy link

coveralls commented Aug 11, 2017

Coverage Status

Coverage decreased (-0.1%) to 38.925% when pulling 91a3ec9 on lindzh:fix_test_exeception into aa1c757 on apache:develop.

1 similar comment
@coveralls
Copy link

Coverage Status

Coverage decreased (-0.1%) to 38.925% when pulling 91a3ec9 on lindzh:fix_test_exeception into aa1c757 on apache:develop.

@coveralls
Copy link

coveralls commented Aug 11, 2017

Coverage Status

Coverage decreased (-0.2%) to 38.742% when pulling c818e36 on lindzh:fix_test_exeception into ccc2235 on apache:develop.

@vongosling
Copy link
Member

How long it would take in your computer ? @Jaskey @vsair, please double check this optimized ut.

new MessageStoreConfig());
assertThat(brokerController.initialize());
brokerController.start();
brokerController.shutdown();
Copy link
Member

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);
Copy link
Member

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?

Copy link
Contributor Author

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++) {
Copy link
Member

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) {
Copy link
Member

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~

@coveralls
Copy link

coveralls commented Aug 14, 2017

Coverage Status

Coverage decreased (-0.06%) to 39.011% when pulling 7c6d268 on lindzh:fix_test_exeception into 332df78 on apache:develop.

try {
master = gen(filterManager);
} catch (Exception e) {
e.printStackTrace();
Copy link
Member

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 ?

Copy link
Contributor Author

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.

Copy link
Contributor Author

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(
Copy link
Contributor

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.

Copy link
Contributor Author

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 @@
/*
Copy link
Contributor

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
Copy link
Contributor

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.

Copy link
Member

@vongosling vongosling Aug 24, 2017

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 ?

Copy link
Contributor

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?

Copy link
Member

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 :-)

Copy link
Contributor

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.

Copy link
Contributor Author

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.

@vongosling
Copy link
Member

@Jaskey @vsair Looking forward to your opinion about this PR

}
//wait for consume queue build
Thread.sleep(100);
Thread.sleep(10);
Copy link
Contributor

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?

Copy link
Contributor Author

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();
Copy link
Contributor

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.

Copy link
Contributor Author

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
Copy link
Contributor

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);
Copy link
Contributor

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 ?

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.4%) to 38.703% when pulling 25e3791 on lindzh:fix_test_exeception into 332df78 on apache:develop.

@vongosling
Copy link
Member

vongosling commented Aug 28, 2017

@lindzh Thanks, I made some modifications and merged this PR. You could close it :-)

@lindzh lindzh closed this Aug 28, 2017
asfgit pushed a commit that referenced this pull request Aug 29, 2017
lizhanhui pushed a commit to lizhanhui/rocketmq that referenced this pull request Jun 25, 2019
lizhanhui pushed a commit to lizhanhui/rocketmq that referenced this pull request Jun 25, 2019
JiaMingLiu93 pushed a commit to JiaMingLiu93/rocketmq that referenced this pull request May 28, 2020
JiaMingLiu93 pushed a commit to JiaMingLiu93/rocketmq that referenced this pull request May 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants