1

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.

ahillman3
  • 976
  • 7
  • 18
  • Can you, for test purposes, replace `ThreadPoolExecutor` with [`MoreExecutors.sameThreadExecutor()`](http://docs.guava-libraries.googlecode.com/git/javadoc/com/google/common/util/concurrent/MoreExecutors.html#sameThreadExecutor())? Also can you define this *context* that is not available in threads? – Tomasz Nurkiewicz Feb 01 '13 at 22:50
  • 1
    If you are hitting a database, that is integration testing, not unit testing – Stephen Connolly Feb 01 '13 at 23:40
  • Do you actually need to be connecting to a DB at all for this test? – imrichardcole Feb 03 '13 at 21:21
  • @TomaszNurkiewicz That is interesting, I'll check that out. – ahillman3 Feb 04 '13 at 14:06
  • @StephenConnolly You are correct, this is actually integration testing. I've already implemented all of the unit tests that were not actually integration. The next challenge, for code coverage was to hit the code that needs DB access to function. – ahillman3 Feb 04 '13 at 14:08
  • @richcoleuk Yes, DB is necessary, as a lot of the runtime behavior functionality is DB dependent. Given the level of testing I'm at to this point, the DB is needed. – ahillman3 Feb 04 '13 at 14:09

1 Answers1

0

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.

Moshe Shamy
  • 117
  • 3