ABSTRACT:

Every programmer write unit tests for their code. Unit tests are so named because they test one
unit of code..Due to lots of pressure of coding work you may write fewer tests. Reduction of tests
leads to less productiveness and less stable code.
Manual unit testing includes overhead of rewriting of test application on new modification,in
code and thus time consumption.
Test-driven development (TDD) is a software development process that relies on the repetition
of a very short development cycle: first the developer writes a failing automated test case that
defines a desired improvement or new function, then produces code to pass .
Test-driven development requires developers to create automated unit tests that define code
requirements (immediately) before writing the code itself. The tests contain assertions that are
either true or false. Passing the tests confirms correct behavior as developers evolve and refactor
the code. Developers often use testing frameworks, to create and automatically run sets of test
cases.
In this paper i introduce a framework. This framework for writing automated, self-verifying tests
in Java,which are called test cases. It provides a natural grouping mechanism for related tests,
which it calls a test suite. It also provides test runners that you can use to execute a test suite.
The test runner reports on the tests that fail, and if none fail, it simply says “OK.”.The tests are
written in a familiar language Java and in a style that is easy to read, even for someone new to
this style of testing.It is a testing framework.• Used by developers to implement unit tests in Java
(de-facto standard)• Integrated with Ant .Testing is performed as part of nightly build process.
Accelerate programming and increase tthe quality of code. Part of XUnit family (HTTPUnit,
Cactus), CppUnit.

Introduction:

Manual Unit testing and test driven development

Manual Unit testing can be time-consuming and tedious. It demands patience and thoroughness
on the part of the development team. Unit testing must be done with an awareness that it may not
be possible to test a unit for every input scenario that will occur when the program is run in a
real-world environment.
Unit tests are released into the code repository along with the code they test. Code without tests
may not be released. If a unit test is discovered to be missing it must be created at that time.
The biggest resistance to dedicating this amount of time to unit tests is a fast approaching
deadline. But during the life of a project an automated test can save you a hundred times the cost
to create it by finding and guarding against bugs. The harder the test is to write the more you
need it because the greater your savings will be. Automated unit tests offer a pay back far greater
than the cost of creation.

Test-driven development offers the ability to take small steps when required. It allows a
programmer to focus on the task at hand as the first goal is to make the test pass. Exceptional
cases and error handling are not considered initially, and tests to create these extraneous
circumstances are implemented separately. Test-driven development ensures in this way that all
written code is covered by at least one test. This gives the programming team, and subsequent
users, a greater level of confidence in the code.
While it is true that more code is required with TDD than without TDD because of the unit test
code, total code implementation time is typically shorter.[10] Large numbers of tests help to limit
the number of defects in the code. The early and frequent nature of the testing helps to catch
defects early in the development cycle, preventing them from becoming endemic and expensive
problems. Eliminating defects early in the process usually avoids lengthy and tedious debugging
later in the project.

Because no more code is written than necessary to pass a failing test case, automated tests tend to
cover every code path. For example, in order for a TDD developer to add an else branch to an
existing if statement, the developer would first have to write a failing test case that motivates the
branch. As a result, the automated tests resulting from TDD tend to be very thorough: they will
detect any unexpected changes in the code's behaviour. This detects problems that can arise
where a change later in the development cycle unexpectedly alters other functionality.

To automatically test the code developers use testing frame work. In this paper I introduce a
testing framework called Junit that implements the Test driven development. One key goal is to
reduce the time taken during manual unit tetsing.

Problem definition:

- Test applications are written and being thrown. Later if any modification is being made in the
code then another test application is made. Large projects will have hundreds of classes and
several class libraries. It is very difficult to write separate test applications for each of the classes
in the project and save all of them for repeated testing in future. Test applications require a
human person to test. You may test several possibilities on the first time, but you may not
remember all of the test cases when you repeat the test in future. When you do manual test, you
are manually verifying the result. Even if the result is wrong, you may not realize it and think
that the test was success.It is not practical to repeat all tests manually before you make a product
release everytime. It will take several hours or days to complete manual unit testing of every
piece of code. Following are the summarized form of problems:-

 The developer must manually setup any initial state to perform the testing. This can be
time consuming and difficult, especially if a complex state is required.
 This type of testing can be error prone and time consuming because the developer cannot
test all possible inputs / outputs.
 There is no way to track the results of this type of test.
 There is no way to track the code coverage of this type of testing. This could lead to
untested code.
 There is no way to integrate your testing with the testing that is done by the rest of your
team. This could lead to changes in your code negatively affecting another team
member's code.
 Because developers must run this type of test manually, there is no way to build up a
suite of tests and make them repeatable.
 Any external resources used or modified during the test must be manually cleaned up.
This could include database records, mainframe records, or temp files on the file system.
High Level Solution:

Junit testing framework provides the automation of testing and thus reduces the developers time.
So it sets more focus on testing the  fundamental building blocks of a system i.e. one block at a
time rather than module level functional testing. This really helps to develop test suites that can
be run any time when you make any changes in your code. This all process will make you sure
that the modifications in the code will not break your system without your knowledge.JUnit
provides also a graphical user interface (GUI) which makes it possible to write and test source
code quickly and easily. JUnit shows test progress in a bar that is green if testing is going fine
and it turns red when a test fails. There is a lot of pleasure in seeing the green bars grow in the
GUI output. A list of unsuccessful tests appears at the bottom of the display window. We can
run multiple tests concurrently. The simplicity of JUnit makes it possible for the software
developer to easily correct bugs as they are found.