How to Test JAVA Applications – Tips with Sample Test Cases (Part 1)

In this tutorial, we will learn the components involved in a Java application and the various types of testing that need to be carried out to ensure a high quality, bug-free application.

This is a three-part series on testing JAVA applications.

  1. In this article, we will learn the J2EE components and Manual testing approach for a J2EE application.
  2. In the second, we will review the Automated testing approach for testing J2EE applications, and
  3. In the third, we will review a comprehensive list of tools that are available for testing J2EE applications.

Testing JAVA Applications

Let’s Start With Overview of J2EE Applications

A Java web application consists of several components, each serving an important purpose. MVC, which stands for Model View Controller, stands as the most popular and frequently used Architectural design pattern.

Before learning to test, let us briefly go through the various components of a J2EE application.


  • Client/Browser asks for a web address with a URL.
  • JSP (Java Server Pages) – JSP is a server-side technology intended to present data to the user. It supports the display of dynamic content with the help of special tags called JSP tags, which help insert Java code within HTML pages. [Static HTML always displays the same content]. At runtime, a JSP is converted to a Servlet. Business logic is not typically written here.
  • JSF (Java Server Faces) – JSF is a view component framework for the effective design of the User Interface.
  • Javascript/Jquery – are scripting languages used for Client side validation of the View/screen.
  • Servlet – A Servlet validates the data received from the input, selects the appropriate business logic code, and passes on the values to the Bean code.
  • Enterprise Java Bean (EJB) – This is where the entire business logic is typically written and handled. The bean then calls the code to either read, write or update the database. Once the database operations are complete, the response is then transferred back to the Servlet, which in turn selects the appropriate JSP to display the results.
  • WebServices – Webservices are components of an application which run on a separate server and communicate over HTTP protocol.
  • Database – stores the entire data of the application.

Please note that not all web applications follow the JSP -> Servlet -> EJB -> Database model. Most of the J2EE applications are currently written with a framework such as Struts, Spring, or Hibernate. The design of applications varies for each requirement based on a size of the application, cost, development time, resources and team size.

Testing JAVA/J2EE Application

Let us now move to testing an entire J2EE application. This is done in several steps. For example, consider that we have three screens:

  • A login screen
  • An employee display screen, which lists all employees in the organization
  • An employee modification/addition/removal screen.

The UI (User Interface) for these three screens are developed with JSP/HTML and the validations performed through JavaScript. Because it is a sample application, logic is in the Servlet and DAO (Data Access Object). DAO is a class for connecting to the database.

Below are the sample screens:

J2EE APPLICATION Testing examples

J2EE APPLICATION Testing Example 2

J2EE APPLICATION Testing Example 3

Manual Java Application Testing:

During manual JAVA testing, a tester prepares the test cases from the detailed design document and tries to cover every scenario and code snippet possible.


Unit testing is a type of testing wherein a user needs to test the smallest of the code snippets for accuracy, correctness and meeting the requirements.

Let us take the example of the login screen. The login screen has two text fields: username and password, and has two buttons: submit and cancel.

The test cases should cover all the loops and conditional statements. Test cases should display the expected results and the test data. Below are some of the general test cases that a user could execute manually in a login screen. The results are then noted down in the test case document.

Below is a sample test case format for the login screen.

S.No.Test CaseExpected ResultActual ResultPass/Fail
1User checks the appearance of labels Username, PasswordThe labels should be correctly spelled and displayed in Normal sized fontThe label username and password are displayed correctlyPASS
2User checks the appearance of the button
Submit and Cancel
The buttons should be displayed with the correct nameThe buttons Submit and Cancel are displayed correctlyPASS
3User checks the background color of the screenThe login form should be within a white table and the screen should be of background greyThe screen appearance does not match the requirements.FAIL
4The user leaves username textbox as BlankError message “Username cannot be empty” should be displayedError message “Username cannot be empty” is displayedPASS
5The user enters some value in the username textbox and leave the password textbox as BlankError message “Password cannot be empty” should be displayedError message “Password cannot be empty” is displayedPASS
6User enters username as “abcd” and password as “xxxx”Error message
“Invalid username password combination”
should be displayed
Error message
“Invalid username password combination”
is displayed
4User enters a username of more than 10 charactersError message
“Username should not be more than 10 characters” should be displayed
Error message is not displayedFAIL
5User enters username as “testuser” and password as “password” and clicks the Submit buttonThe user should be able to see the “Employee details screen”Employee details screen is displayedPASS

While table lists some of the test cases, below is the complete list:

  • Check for any exception including NULL pointer exception
  • Check if NULLS are not allowed for username and password
  • Check if username/password is in the correct format
  • Check if numbers are not allowed for username
  • Check if special characters are not allowed in Username
  • Check if the correct combination of Username and password are entered, then the application takes you to the next screen, i.e. employee information screen
  • Check if the username entered is of correct length
  • Check if the username text field allows only the maximum number of characters specified for that field
  • Check if the password field if specified in the requirements is visible as * while entering
  • Check if passwords are case sensitive
  • Check if username is not case sensitive
  • Check if login page does not remember the username or password, even after exiting
  • Check if the Submit and Cancel button work as per requirement
  • If using the application first time, check if the username has permission to enter the application
  • Delete a username/password combination from the database and check if the combination is not able to login again
  • For all the above cases, check if the appropriate validation error messages are shown
  • Check if the Labels and Buttons are in the right place on the screen and that they display the text correctly
  • Check if the screen appearances are as per requirements
  • Check if exceptions are handled
  • Check if logging is performed for required actions

After going through the test cases, you may realize that you are mostly dealing with the testing of fields, buttons, functionality, and validations of a particular screen. This is accurate, as Unit Testing very keenly deals with the testing of every small code snippet and component. The same type of testing should be performed for all the screens.

Please note that the above are examples only, and test cases are prepared based on a project-specific and detailed design document.

Read Also => Sample ready to use test cases and test scenarios for web application testing.


In Integration testing, individual modules are integrated and tested together for correctness.

Let each of the three screens in the above example is developed by three different team members. Now that they are finished with Unit testing, it is time to bring all the code together and check if they work well together. Integration testing is performed to ensure that data or control is transferred correctly from one screen to another.

Here are some sample integration test cases for the Employee Application example:

  • Check if the user logged in and session are the same in all the other new integrated screens
  • Check if the other modules are not updating/deleting/inserting any record in the database unrequired
  • Let there be an employee status field, which says ‘New’ on addition,’Updated’ on modification, and ‘Deleted’ on deletion. Though two or three screens can use the same status field, it is important to ensure the field is not being wrongly updated.
  • Check if the header, footer, screen size and appearance meet requirements after integration
  • Check that when clicking on Submit buttons, the control is transferred to the next screen
  • Check that when clicking on the Cancel button, the action performed is canceled

In addition, the general integration test cases for a J2EE application could be:

  • Check the flow of data, either Object, XML or Session from end to end. Check for correctness.
  • Check whether the session is managed correctly by each of the modules
  • If external applications (web services) are involved, check whether your application is able to make calls and retrieve data back from the application


In System testing, the entire application is tested for functionality and completeness with respect to the requirements. It would likely be easier to ask when Unit testing of every component is performed and the code components are also combined and tested together during integration testing, what could be different in System testing? It is not inaccurate to say that the idea in System Testing is to break the application 🙂

Scenario #1: You develop a new employee application with a framework; for example, Struts. There are also several other applications running on different servers in your organization. However, all of them call the same existing web service to fetch the address and phone number for any particular person.

During integration testing, you would have tested if your application is able to make a call to the web service and if you are able to get the response. But what if there is a problem in the web service itself? Or the web service does not respond to some rare inputs? The web service, in our case, can only take an employee number max of 6 characters. Or, the web service throws exceptions for certain formats of address while returning. This is external, but it also part of System testing.

Scenario #2: Your employee application is complete. You add an employee, and it generates an Employee Number #1001. You modify, delete, update, add, modify, delete, add, add, add, modify, delete and then finally add another. What if the new employee number is again #1001?

Scenario #3: Let us assume two users are using the application at the same time. Both of them start working on the same employee, one deletes. What if the other user is able to proceed with the modification of same employees as it is stored in the session?

Below are some important aspects of System testing:

  • Ensure the flow of data and control is correct from end-to-end
  • Ensure security of the transaction data
  • Ensure the application follows all business functionalities
  • Check if the application works well as an end product – check broken links, session management, cookies, logging, error handling, exception handling, validation, and transaction flow.


This type of testing is performed when there would be a large number of users using the application or large amount data in the database, or both. Below are some of the cases:

  • If multiple users login at the same time, then check that the applications do not hang/crash
  • If a large amount of data is available in the database – check that the search screen grids do not take very long to execute queries before session timeout
  • In a multi-threaded environment, check that the application is able to handle all threads well
  • In applications where large numbers of objects are created, check whether sufficient memory is allocated, garbage collection is handled, and that there are no out of memory exceptions


In this article, we have covered an overview of a J2EE application. We have also seen how to manually perform Unit, Integration, Functional and System testing for each of the components of the application with an example.

In the next article, we will see the how Automation testing can be beneficial for large J2EE applications.

About Author: This is a guest article by Padmavaty S. With overall 7+ years of software testing experience she is having extensive experience in testing Java, J2EE, MVC, and Struts framework.

Let us know if you are working on testing JAVA applications. Share your experience and queries in comments below.

PREV Tutorial | NEXT Tutorial

Recommended Reading

23 thoughts on “How to Test JAVA Applications – Tips with Sample Test Cases (Part 1)”

  1. Hi:

    Still confuse Why you are calling this article as “J2EE Application/Website testing”

    As per my knowledge, It dose not matter which technology is used to make the application, above testing are same for all – Unit, Integration, and System.

    I read somewhere, that tester should have expertise in 3 field mainly- Domain, AUT (Application under test) and Technology.

    But from my 4 years of QA experience I encountered that…. Testing (Black BOX) is not concern with what technology is used.

    If I am wrong please correct me with your POV.

    In any case, Its Great Article – Looking forward to see more 2 Parts ASAP.


  2. Useful article. waiting for the next ones as well

  3. Informative article!!
    I have one doubt ,JavaScript /J query i used for validations as u mention in there any testing scope for this validations?
    with use of firebug,few values can be interchanged , at this time i my testing career i saw that application failed at this point ..

  4. Informative article!!
    I have one doubt ,JavaScript /J query is used for validations as u mention in there any testing scope for this validations?
    with use of firebug,few values can be interchanged , at this time in my testing career i saw that application failed at this point ..

  5. the article is very well explained, thanks to Padmavaty S, i have a query here, what all are the scenarios we can cover during UAT testing for this app. Please explain.

  6. very useful for us ,very good one ,waiting for next.

  7. Hi @Tejaswini, JavaScript and JQuery are used for validations to be performed at screen level. There are again two ways of testing them. Manual and automated. In manual testing, the tester needs to recreate the scenario when the validation error would occur. If automated testing is chosen, then there are several open source tools like Jsunit,Jasmine,Qunit an overview of which will be covered in the coming articles.

  8. Hi @Sachin,
    Thanks for your feedback. Testing knowledge required for an application depends on the technology used, its complexity and type of testing. Domain knowledge is required to understand the business flow. Application knowledge is required to understand the functionality the application performes. For large complex heavily technical applications, it will be a plus if the tester has basic insight on the technology used for the application. As for the type of testing, I have noticed that in many manual testing scenarios, technological knowledge is not required as much as in Automated testing. And in Unit testing, as it deals with code level may require the tester to have basic understanding of the programming language involved. Hope this helps.

  9. Hi @Deepti,
    Thanks for your feedback. As you may be aware that UAT is quite different from System Testing(which is usually the last stage in testing by the development team). The UAT is performed by the user and these users are the ones who actually initiated the code changes and specify the requirements. They usually test what they are looking for in the application. Though in most projects, the User signs off the understanding of requirement by the development team at every stage, it is only after System Testing that they usually get to really see the application. When they start testing, they would like to see and test if the changes made to the application are as per the requirement specified. For this application, the user may want to perform a complete testing which would be a combination of Unit, Integration, System and performance. The user may have his/her own test plan and it may cover or exclude some of the test cases. In large applications, the user may mainly perform Functional testing. Hope this answers your question.

  10. Good article…waiting for next 2 articles.

  11. hi,
    nice article to get the information on to test java application
    When can we get the next continued part of this article.
    Waiting to see the next part.

  12. Hello Padmavaty, Thanks for an useful article.

  13. Good article Padmavaty, way to go!!

  14. Useful info. Can you please explain about the third scenario of system testing?
    If it happens how to handle and what is a tester role here?


  15. Article started in the right spirit but later on it moved to generic terminology of unit/integration and system testing , i echo the statements made by Sachin(first comment)

  16. Hi, padmavathi this Akbar. I like your article very much as it is in detail enhancement of software testing life cycle. I doing software testing course with manual and QTP. I have question that is i required linux os knowledge for testing applications to get software testing job. Hope you will clarify my doubt. Please mail me your suggestion.

  17. i have a one doubt i had done the xml based projects so is there any used to qtp.

  18. As I am new in testing field so this article is very helpful for me, Thanks for the descriptive steps. Waiting for the more articles as well.


  19. Thanks alot , it’s very benificial and inforamtive and Clear
    please give us more

  20. Thank you very much.I have so many doubts about the block box testing so far,But after this article all doubts were cleared.I want to automate the “online exam sessions ” with selenium web driver. How? give me an idea Thanks in advanced.

  21. Absolutely agree with this post, all tips and suggestion are great but can you please tell me that what is JVM exactly and why is it required and what is the difference between Path and Classpath?

  22. Good article Padmavaty.

  23. JSUnit is an open source Unit testing framework for JavaScript. If you are familiar with JUnit, then you will have no difficulty learning JSUnit. It is an extension of JUnit for JavaScript testing.


Leave a Comment