Question

Here’s a fun one.

I have an an application that runs under tomcat with servlet access. The underlying implementation uses a ThreadPoolExecutor to subdivide the tasks, at this point just an email distributor. I have been adding JUnit tests, slowly getting the code coverage as reported by cobertura to an almost acceptable level.
Some background on the JUnit testing in place:

1. In the @BeforeClass I am setting up the context for DB connection lookups that are valid in the test environment.
2. In the Servlet test, I am using HttpUnit to acquire an InvocationContext and then an instance of the servlet.
3. Then, I call the primary method in the servlet that does all of the work, and eventually calls out to a thread manager for the appropriate distribution method, and uses the ThreadPool defined earlier.
4. The problem occurs in the spawned threads. The DB access from the servlet works just fine using the created context setup in the @BeforeClass. The Threads don’t have access to that context, and fail to get DB Connection info, causing failures in the Thread code.

So, bottom line, anyone have an idea how to test the Thread code, that wants DB access? Or even an entirely new method of unit testing that would work with a multithreaded application that wants DB access.

Any additional details can be provided to a point. I hope I have provided enough information, that providing actual code won’t be necessary.

Answer 1

I suggest extends the task that sent to the threadpool and add the DB context to the extended task and than in the new test that you wrote take the context and use it for accessing to the database.
I hope it’s answer your question, if not please add some code example so i will be able to test it.