These days m testing a huge multithreaded application with JUnit. Faced lot of issues during the tests, but could not find aapropriate answers for them yet. Forced to change the base code to be tested, which I know will not be acceptable by our client, its not practical also. Why one will change its code to be a non multithreaded if he requires it in its app. First and the biggest problem came accross when there were Thread.sleep() calls and the app. is supposed to be running forever. To put an example here, the application is developed to run endlessly checking for some data in the DB, if it finds any, it proccesses it and sleep for some interval, and the process goes like that forever. So does the JUnit test, it will not come out again. Second issue was more surprising. When there is a new thread started, JUnit care least to wait for it to complete its work, it will just come out as it doesnt know its running for a multithreaded app. Seems it doesnt understand threading. There are few issues other than MT like having System.exit(n) in your code. When your testcases hits a function having System.exit(n), the behavior of JUnit suddenly gets changed. You wont get proper report from JUnit. And one just keeps on thinking what went wrong. Would appreciate inputs on the issues.
Maybe you shouldn't be testing all of those features with JUnit? Have you tried googling for "junit" and "multithreaded"? I remember seeing some articles about writing JUnit tests for multithreaded applications.
I googled for these issues. The articles you mentioned are those which demonstrate testing you code from multithreaded testcases as JUnit only supports single threaded testcases. FYI. MTJUnit & JMTUnit are the frameworks for achieving it. My problem still exists, I dont need multiple threads testing my code. I need some way to test my multithreaded application, irrespective how many test threads are testing it. I hope I am clear in my point.
posted 16 years ago
Are there other aspects than the "wakes up every X minutes to do some processing" feature that you'd like to test using JUnit? I think I'd try to write tests for the "processing" part as usual and then write a test for the "wake up every X minutes" part separately by adding a setInterval(3000) to the trigger code or whatever, and simply Thread.sleep(3000) before asserting that the trigger has went off exactly twice.
Yeah i tried it but its not convinient and foolproof, you never know how much time its gonna take for processing, it depends on the volume of data fetched from the database. So everytime it will be a different duration.
I had some thread testing problems, too, as JUnit couldn't realize it was on a multithread situation. I needed to test the integration of two ( actually n) objects from the same class, and that was so complicated.
I'm not sure if that could help you, but my solution goes as follows: I listed the 'states' my thread could be in, and in wich circunstances it would call or be called by another instance. Then I created a test class that would (1) create two instances of my tested class, (2) link them, so called and callee know each other, (3) put the tested Objects on one of the mapped states and finally (4) ask the callee to call a method of the other object...
It doesn't test everything I needed, but it was a good start point. Hope that helps.
You were trained to handle mission impossible; 'difficult' should be a walk in the park for you.
posted 16 years ago
Thanks for your input! Actually what I done for the problem was something similar but the issue is how to break the ongoing process of the application for JUnit to resume and assert the method if there is Thread.sleep() cals in it.
posted 16 years ago
the issue is how to break the ongoing process of the application for JUnit to resume and assert the method if there is Thread.sleep() cals in it.
I think you're trying to test too big a piece. Let's say that you have a Launcher class, which is responsible for creating the worker thread--instance of class Worker--to the background. Now, try to write a test or two for the Launcher class by handing it a mock implementation of Worker. That way, once the Launcher is done, you can simply call verify() on the Worker instance and it will assert that the Launcher invoked the correct methods on it etc. Then, write a separate bunch of tests to test the Worker class.