Hi YongHao,
On 03/18/16 17:24, YongHao Hu wrote:
dlls/msvcr120/tests/msvcr120.c | 300 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 300 insertions(+)
I don't think this is a good approach for adding tests of critical_section class. Executing tons of enter/leave calls is not really testing much. Your test_critical_section_lock tests will probably pass if you comment all critical section related calls out (it passed on my computer in 10 consecutive runs, never failed, probably it's because the code was optimized during compilation). Testing 5s/6s timeouts is also not a good idea. Because of it the tests are running much longer.
It would be much better if you test following things: - just check some basic functionality of enter/leave: enter cs in main thread, start new thread that tries to enter it as well, wait for 100ms and check that it was not able to enter the cs, then leave cs in main thread and wait for thread to enter cs and finish - check some basic functionality of try_lock: use it to lock the cs, check if it fails on locked cs
Also the tests failed on testbot, I was not checking why.
Thanks, Piotr
Hi Piotr,
On 16/3/22 下午10:29, Piotr Caban wrote:
Hi YongHao,
On 03/18/16 17:24, YongHao Hu wrote:
dlls/msvcr120/tests/msvcr120.c | 300 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 300 insertions(+)
I don't think this is a good approach for adding tests of critical_section class. Executing tons of enter/leave calls is not really testing much. Your test_critical_section_lock tests will probably pass if you comment all critical section related calls out (it passed on my computer in 10 consecutive runs, never failed, probably it's because the code was optimized during compilation). Testing 5s/6s timeouts is also not a good idea. Because of it the tests are running much longer.
How long is a test running acceptable? I want to know a appropriate standard.
It would be much better if you test following things:
- just check some basic functionality of enter/leave: enter cs in
main thread, start new thread that tries to enter it as well, wait for 100ms and check that it was not able to enter the cs, then leave cs in main thread and wait for thread to enter cs and finish
- check some basic functionality of try_lock: use it to lock the cs,
check if it fails on locked cs
Thank you for your comment, it's of great help. I will try it.
Also the tests failed on testbot, I was not checking why.
The tests failed on w2008s64(64bit msvcr120), however, it succeed on 32bit msvcr120. I did not figure out this.
Thank you.
On 03/22/16 17:28, YongHao Hu wrote:
How long is a test running acceptable? I want to know a appropriate standard.
There's no rule for that. In most cases 100ms wait is long enough to make sure something works. Of course if the test is useful and it can't be written to end quickly it can take much longer. I'm trying to avoid tests that calls Sleep if possible.
Thanks, Piotr
On Tue, 22 Mar 2016, Piotr Caban wrote:
On 03/22/16 17:28, YongHao Hu wrote:
How long is a test running acceptable? I want to know a appropriate standard.
There's no rule for that. In most cases 100ms wait is long enough to make sure something works. Of course if the test is useful and it can't be written to end quickly it can take much longer. I'm trying to avoid tests that calls Sleep if possible.
The TestBot and WineTest impose a 2 minute limit on individual tests (like msvcr120:msvcr120 or kernel32:process).
Furthermore the TestBot imposes a 30 minute limit on the full test suite. At 585 tests (and growing all the time), this only allows an average of about 3 seconds per test. But of course some tests take much longer so the remainder must be much faster to bring the average down.
-
Francois Gouget -
Piotr Caban -
YongHao Hu