1

I have never testing a program in Java, cause most of them are not multithreading, now the result is vary depends on time and luck, which is bad. I don't want my code not working when needed, example.

Currently my program I developed has worked as expected, and now since it is a concurrent programming with threads, I need to run like 100x and then a random error occurred. I did not want the program to to go infinite loop, instead of closing program.

Example Result:

Exit: Bus 37 exit the store
Size of Shop: 0
Cleaner : We're closing now!
Cleaner : We're closing now!
Depot : We're closing now!
Mechanics : We're closing now!
Mechanics : We're closing now!
Parking: We are closing now!

Process finished with exit code 0

This is the result when the program is OK

And sometimes the Result is this:

Ramp: Bus 37 using the ramp
Size of Shop: 2
Size of Shop: 2
Ramp: Bus 37 exit the ramp
Exit: Bus 37 exit the store
Size of Shop: 1
Size of Shop: 1
Size of Shop: 1
Size of Shop: 1
Size of Shop: 1
Size of Shop: 1
Size of Shop: 1
Size of Shop: 1
Size of Shop: 1
Size of Shop: 1
Size of Shop: 1
Size of Shop: 1
Size of Shop: 1
Size of Shop: 1
...

As seen here it goes forever, caused the program not exit. Is there a way to testing like 100x, make sure the program is close, which I can fix later on.

I just need the tools to make sure the Java will exit, as this is the condition for a successful program.

GhostCat
  • 137,827
  • 25
  • 176
  • 248
liejoes1
  • 157
  • 1
  • 14
  • From what you show us, it as nothing to do with multithreading, but more with stop conditions on your program. Please give us more details if you want us to help you – DamCx Apr 27 '18 at 09:20
  • Hi @DamCx, the program works no problem, only I don't know a tool that can run the program like 100x (Example), to make sure error occured, so that I can fix it. Currently the problem is just based on luck. And the second result I **forced it to show error** to show context, as this is the error that might be happened – liejoes1 Apr 27 '18 at 09:22
  • This is close to being too broad. You see, writing multi threaded code, and writing such code that it can be easily unit tested is almost a form of art. It takes a ton of experience to get that right. But the fact that you actually think that the type of IDE matters in any way here ... basically tells us that you don't even understand the problem you are looking at. From that point of view: start reading books and tutorials about multi-threading. Practice, practice practice. – GhostCat Apr 27 '18 at 09:38

1 Answers1

5

Make no mistake: you are asking for tools to act as band-aid to mediate a symptom.

That is the wrong approach. You want to fix the underlying bug. If your code doesn't behave deterministic, then most likely, because you put a bug into it. You are basically asking "how do I change my tests to ignore the problem". And the answer to that is: "you don't. you fix the issue".

So you should ask yourself instead: how can I fix the underlying problem?

There are many ways to get there, one of the most helpful ones in my eyes: look into using a same thread executor service.

The point is: in order to be able to test multi-threaded applications, you have to architect the program in ways to allow that.

Example: using "raw" thread objects is a bad idea. Instead, you want to clearly separate functionality. Into parts that work "on their own", to then have additional classes that take care of running things in parallel.

One helpful abstraction here: the ExecutorServce. You simply push "tasks" into that service, and the service can use multiple threads for processing. Thing is: using the aforementioned "same thread executor" you can enable yourself to run tests ... in a single threaded way. Then all that "random" can be greatly reduced.

GhostCat
  • 137,827
  • 25
  • 176
  • 248