Unit Testing

The Basics of Unit Testing

What is Unit Testing?
Test-drive is a level of software testing process in individual units or components or system software are tested. The objective is to validate that the software performs as designed.

A unit is the smallest testable software. Usually have one or few inputs and usually a single output. In planning a unit of procedure may be an individual program, function, procedure, etc. The object-oriented programming, the smallest unit is a method, which may belong to a base / super class, abstract class or derived / class children. (Some treat an application module as a unit. This is to be discouraged because there are likely many individual units within that module.)

The unit testing frameworks, drivers, heels and mock or fake objects are used to help test the unit.

When performing the test drive?
Unit testing is done before integration testing.

Who performs the test drive?
Unit testing is normally performed by the software developers themselves or their peers. In rare cases, can also be done by independent testers.

What test method is used in Unit Testing?
Unit Testing is done primarily through the method of White Box testing.

What are the benefits of Unit Testing?
* Unit testing increases confidence in changing / maintenance of code. If good unit tests are written and if they are run each time you change any code, the probability of default due to any change in the early caught is very high. If unit testing is in place, the most we can do is hope for the best and hope the test results at the higher levels of proof are out. Furthermore, if the codes are interdependent and do less to make unit testing possible undesired effects of changes to any code is smaller.
* Codes are more reusable. In order to make unit testing possible, the code should be modular. This means that the codes are easier to reuse.
* The development is faster. How? If you do not have unit testing in place, write the code and carry out that test developers fuzzy '(set some breakpoints, fire up the user interface, offering a few tickets are expected to reach its code and hope that you are all set.) If you have unit testing in place, write the test code and run the tests. Writing tests takes time, but time is offset by the time it takes to run the tests. The test will have very less time: No need to switch the user interface and provide all inputs. And, of course, unit tests are more reliable than "developer testing. The development is faster in the long run also. How? The effort required to find and fix defects found during unit testing is a pittance compared with those found during system testing or acceptance testing.
* The cost of fixing a defect discovered during unit testing is minor compared with that of the defects detected at higher levels. Compare the cost (time, effort, destruction, humiliation) of a defect detected during acceptance testing or say when the software is live.
* Debugging is easy. When a test fails, only the most recent changes must be debugged. With the tests at higher levels, changes in the span of several days / weeks / months you have to debug.
* Codes are more reliable. Why? I think there is no need to explain this to a healthy person.

Unit Testing Tips-
* Find a tool or framework for your language.
* Do not create test cases for "all": some will be handled by themselves. "Instead, focus on tests that affect the behavior of the system.
* Insulate the development environment from the test environment.
* Using test data that is close to production.
* Before setting a default, write an essay that exposes the defect. Why? First, who will later be able to catch the default if not addressed adequately. Second, the test is now broader. Thirdly, it is likely too lazy to write the test after it has already "fixed" the defect.
* Write test cases that are independent of each other. For example, if a class depends on a database, not writing a case that interacts with the database to test the class. Instead, create an abstract interface that respect around the database and run the interface with the object of derision.
* It aims to cover all routes through the unit. Pay special attention to the conditions of the loop.
* Make sure you are using a version control system to keep track of their code and their test cases.
* In addition to writing cases to verify the performance, type of cases to ensure compliance with the code.
* Perform unit tests continuously and frequently.