In my previous posts , we saw some of the interesting scenarios in Interoperability. Having covered this area lets check out some of the “must know “ aspects and areas under Unit Testing.
Frequently Used Terminologies
Test Driven Development :
Test-driven development (TDD) is an advanced technique of using automated unit tests to drive the design of software and force decoupling of dependencies. The result of using this practice is a comprehensive suite of unit tests that can be run at any time to provide feedback that the software is still working. This technique is heavily emphasized by those using Agile development methodologies.
click here for detailed information.
The primary goal of unit testing is to take the smallest piece of testable software in the application, isolate it from the remainder of the code, and determine whether it behaves exactly as you expect. Each unit is tested separately before integrating them into modules to test the interfaces between modules. Unit testing has proven its value in that a large percentage of defects are identified during its use.
The most common approach to unit testing requires drivers and stubs to be written. The driver simulates a calling unit and the stub simulates a called unit. The investment of developer time in this activity sometimes results in demoting unit testing to a lower level of priority and that is almost always a mistake. Even though the drivers and stubs cost time and money, unit testing provides some undeniable advantages. It allows for automation of the testing process, reduces difficulties of discovering errors contained in more complex pieces of the application, and test coverage is often enhanced because attention is given to each unit.
MSDN info gives detailed insight on this.
Test scenarios represent a powerful tool for test development. In general scenario defines an own model of target system, called the testing model. Scenario must define the state class for this model and the transitions, which must be described in terms of target methods
A test case in software engineering is a set of conditions or variables under which a tester will determine whether an application or software system is working correctly or not. The mechanism for determining whether a software program or system has passed or failed such a test is known as a test oracle. In some settings, an oracle could be a requirement or use case, while in others it could be a heuristic. It may take many test cases to determine that a software program or system is functioning correctly. Test cases are often referred to as test scripts, particularly when written. Written test cases are usually collected into test suites.
More info on this Wiki page.
Code coverage is a measure used in software testing. It describes the degree to which the source code of a program has been tested. It is a form of testing that inspects the code directly and is therefore a form of white box testing. In time, the use of code coverage has been extended to the field of digital hardware, the contemporary design methodology of which relies on hardware description language(HDLs).
Code coverage techniques were amongst the first techniques invented for systematic software testing.
Detailed info is here.
Unit testing frameworks, which help simplify the process of unit testing, have been developed for a wide variety of languages as detailed in this list of unit testing frameworks. It is generally possible to perform unit testing without the support of specific framework by writing client code that exercises the units under test and uses assertions, exception handling or other control flow mechanisms to signal failure. This approach is valuable in that there is a barrier to entry for the adoption of unit testing; having scant unit tests is hardly better than having none at all, whereas once a framework is in place, adding unit tests becomes relatively easy.
Detailed list of unit testing framework is worth having look at.
Okay ! Enough of theory .. isn’t it ??
We talked about Twists and Twirls .. where are they ???
We will be coming across them from next post as we go ahead and see the actual examples. Getting used to this terminologies is really important and we will need them as we see various aspects of Unit Testing.
Till then .. Have a Nice One 🙂