Any application that is written usually has a user interface associated with it so that users can interact with the system (for eg: inputting data, generating reports based on data that exists in databases, etc.).


For application developers, testing forms an integral part of the development life-cycle. As old code is modified for reasons ranging from adding new functionality to speed optimizations, the risk of dependent functionality getting broken increases. Tests that are written once, and can be run repeatedly is the only solution to avoid manually QA testing. To write these tests, for applications written in java, JUnit provides a solid framework for writing unit tests. Many JUnit integrations also exist to integrate your JUnit tests into build and development tools. 

User Interface Layer (Java)
|
|
Front-end Business Layer (Java)
|
|
Middle Layer (i.e. 3rd party in Java)
|
|
Back-end (eg: Forte/COBOL programs)
|
|
Database Layer

Looking at the figure above, we can see that tests can be written at any layer (on a "method level", i.e. the developer can call methods passing in specific parameters and check the obtained results with what (s)he manually calculated), which traverses all the layers below it and returns with the results of whatever processing it is supposed to perform. This forms the basis of testing with JUnit. So testing at any layer can be considered to be a "coarser" grained testing of the level below it. Interface test harnesses can also be created to mimic the operation of  lower levels, and allow the test cases to be isolated to a single level.. 

But one important facet that usually gets side-lined, is that since all the testing involves only method calls, this practice cannot be directly applied for testing the UI layer. And if the UI layer is not tested, there still exists some chunk of the application pie that is "untested". Another point in the practical sense, is that method calls are done in real-time, whereas the testing script/framework should allow for the JVM to render the UI objects, before proceeding with the tests.

While writing GUI tests, the developer has to "mimic" a user's interaction with the application screen being tested. This means that the simple process of selecting a value in a combo box, involves the following steps:

  1. Locate the window object on the screen.
  2. Find the combo box in the component hierarchy of the window object.
  3. Scroll through the various elements of the combo box, to find the required one.
  4. Select the required element index.

Similar conversion of semantic to programmatic actions provide the need for jfcUnit and its specific "style" of testing Java applications at the UI layer.