Home/ Questions/Q 8769641
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-13T17:23:25+00:00

I am basically practicing with Java socket programming by building client and server (not

  • 0

I am basically practicing with Java socket programming by building client and server (not necessarily HTTP server). In brief, the clients are sending request through sockets to server and server adds requests to task queue. The thread pool initially has certain number of threads and each free one is assigned to one runnable task in the task queue. My web server also has a simple storage that stores and retrieves data from a file from disk. In this project, I have to take care of several concurrency issues.

Basically, I have to build client, server, thread pool, handler, storage. However, I want to test thoroughly in a good systematic way (unit test, integration test, etc.). I don’t have much experience in testing so I am looking for pointers, methodologies, frameworks, or tutorials. (I use Ant to automate building, and initially consider JUnit and EasyMock for testing)

architecture

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Before testing, I’d start by coding some rough and ready prototpye code. Just to see it working and to get a feel for the APIs I will be using.

    Then introduce some unit tests with JUnit (there are other frameworks but JUnit is ubiquitous, and you’ll find plenty of tutorials to get you started).

    If your object needs to interact with some other Objects to complete it’s tasks, then use mocks (EasyMock or whatever) to provide the interaction – this will probably lead to a bit of re-factoring.

    Once you are happy, you can start to look at testing how your Objects interact, you can write new (integration) tests that replace the Mocks with the real thing. Greater interaction results in greater complexity.

    Some things to remember

    • trivial methods aren’t worth testing (e.g. simple accessors)
    • 100% coverage is a waste of time
    • any test is better than none
    • Unit test is easier to achieve than integration test
    • Not all tests are functional
    • Testing multi-threaded applications is hard

    There is a book on how Google does testing. Basically they don’t write tests until something looks viable. They have engineers who advise on how to structure code for testing. The point is:

    • Runnable code is the goal
    • Tests add to that goal, but do not replace it
    • Writing code that can be tested is a learnt skill
    • 0