Unit Testing :Tutorial 4
Unit testing of software applications is done during the development (coding) of an application.
The objective of unit testing is to isolate a section of code and verify its correctness. In procedural programming a unit may be an individual function or procedure
The goal of unit testing is to isolate each part of the program and show that the individual parts are correct. Unit testing is usually performed by the developer.
Why do Unit Testing? Why it is important?
Sometimes software developers attempt to save time by doing minimal unit testing. This is a myth because skimping on unit testing leads to higher defect fixing costs during system testing, integration testing and even beta testing after the application is completed. Proper unit testing done during the development stage saves both time and money in the end.
Building unit Test Cases
Unit testing is commonly automated, but may still be performed manually. The IEEE does not favor one over the other. A manual approach to unit testing may employ a step-by-step instructional document.
Under the automated approach-
- A developer could write another section of code in the application just to test the function. They would later comment out and finally remove the test code when the application is done.
- They could also isolate the function to test it more rigorously. This is a more thorough unit testing practice that involves copy and pasting the function to its own testing environment to other than its natural environment. Isolating the code helps in revealing unnecessary dependencies between the code being tested and other units or data spaces in the product. These dependencies can then be eliminated.
A coder may use a Unit Test Framework to develop automated test cases. Using an automation framework, the developer codes criteria into the test to verify the correctness of the unit. During execution of the test cases, the framework logs those that fail any criterion. Many frameworks will also automatically flag and report in a summary these failed test cases. Depending upon the severity of a failure, the framework may halt subsequent testing.
Building unit Test Cases
Unit testing is commonly automated, but may still be performed manually. The IEEE does not favor one over the other. A manual approach to unit testing may employ a step-by-step instructional document.
Under the automated approach-
- A developer could write another section of code in the application just to test the function. They would later comment out and finally remove the test code when the application is done.
- They could also isolate the function to test it more rigorously. This is a more thorough unit testing practice that involves copy and pasting the function to its own testing environment to other than its natural environment. Isolating the code helps in revealing unnecessary dependencies between the code being tested and other units or data spaces in the product. These dependencies can then be eliminated.
A coder may use a Unit Test Framework to develop automated test cases. Using an automation framework, the developer codes criteria into the test to verify the correctness of the unit. During execution of the test cases, the framework logs those that fail any criterion. Many frameworks will also automatically flag and report in a summary these failed test cases. Depending upon the severity of a failure, the framework may halt subsequent testing.
Mock Objects
Unit testing relies on mock objects being created to test sections of code that are not yet part of a complete application. Mock objects fill in for the missing parts of the program. For example, you might have a function that needs variables or objects that are not created yet. In unit testing, those will be accounted for in the form of mock objects created solely for the purpose of the unit testing done on that section of code.
Unit Testing Tools
There are several automated tools available to assist with unit testing. We will provide a few examples below:
- Rational Software – Rational Software by IBM has a unit test feature known as “Rational Test Realtime”. The software contains a complete range of testing tools for much more than just unit testing. It is used for Ada, Java, C and C++. It creates unit tests by reverse engineering the software. Operating systems it supports include Windows, Linux, Solaris, HP-UX and AIX. Go to http://www-01.ibm.com/software/rational/ to learn more.
- JavaScript Assertion Unit– Also known asjsAsserUnit,this Freeware JavaScript unit testing tool can be used on any platform that supports JavaScript. It is available at http://jsassertunit.sourceforge.net/docs/index.html
- CUT – CUT is a Freeware unit test tool for C, C++ and Objective C. It is great for embedded software testing frameworks and desktop applications on Linux and Windows operating systems. Learn more at sourceforge.net by going to http://sourceforge.net/projects/cut/.
- Dotunit – Dotunit is a .net framework Freeware unit testing tool. Part of Junit on the Microsoft .net framework, Dotunit is used for automating unit testing on windows systems. This is another tool from sourceforge.net, so look for it at: http://dotunit.sourceforge.net/
Those are just a few of the available unit testing tools. There are lots more, especially for C languages and Java, but you are sure to find a unit testing tool for your programming needs regardless of the language you use.
Extreme Programming & Unit Testing
Unit testing in Extreme Programming involves the extensive use of testing frameworks. A unit test framework is used in order to create automated unit tests. Unit testing frameworks are not unique to extreme programming, but they are essential to it. Below we look at some of what extreme programming brings to the world of unit testing:
- Tests are written before the code
- Rely heavily on testing frameworks
- All classes in the applications are tested
- Quick and easy integration is made possible
Unit Testing Myth
It requires time and I am always overscheduledMy code is rock solid! I do not need unit tests.
Myths by their very nature are false assumptions. These assumptions lead to a viscous cycle as follows –
Truth is
Unit testing increase the speed of development.
Programmers think that integration testing will catch all errors and do not unit test. Once units are integrated, very simple errors which could have very easily found and fixed in unit tested take very long time to be traced and fixed.
Unit Testing benefits
- Developers looking to learn what functionality is provided by a unit and how to use it can look at the unit tests to gain a basic understanding of the unit API.
- Unit testing allows the programmer to refactor code at a later date, and make sure the module still works correctly (i.e. Regression testing). The procedure is to write test cases for all functions and methods so that whenever a change causes a fault, it can be quickly identified and fixed.
- Due to the modular nature of the unit testing, we can tests parts of project without waiting for others to be completed.
Unit Testing Limitations
- Unit testing can’t be expected to catch every error in a program. It is not possible to evaluate all execution paths even in the most trivial programs
- Unit testing by its very nature focuses on a unit of code. Hence it can’t catch integration errors or broad system level errors.
Its recommended unit testing be used in conjunction with other testing activities.
Unit testing best practices
- Unit Test cases should be independent. In case of any enhancements or change in requirements, unit test cases should not be affected.
- Test only one code at a time.
- Follow clear and consistent naming conventions for your unit tests
- In case of change in code in any module, ensure there is a corresponding unit test case for the module and the module passes the tests before changing the implementation
- Bugs identified during unit testing must be fixed before proceeding to the next phase in SDLC
- Adopt a “test as you code” approach. The more code you write without testing the more paths you have to check for errors.
Summary
As you can see, there can be a lot involved in unit testing. It can be complex or rather simple depending on the application being tested and the testing strategies, tools and philosophies used. Unit testing is always necessary on some level. That is a certainty.
SDLC , STLC & V-Model: Testing Tutorial
 |
Video Transcript with Key Takeaways Highlighted:
- Suppose, you are assigned a task, to develop a custom software for a client.
- Each block below represents a step required to develop the software.
- Irrespective of your technical background, try and make an educated guess about the sequence of steps you will follow, to achieve the task
- The correct sequence would be.
- Gather as much information as possible about the details & specifications of the desired software from the client. This is nothing but the Requirements gathering stage.
- Plan the programming language like java , php , .net ; database like oracle , mysql etc which would be suited for the project. also some high level functions & architecture. This is the Design Stage.
- Actually code the software. This is the Built Stage.
- Next you ,Test the software to verify that it is built as per the specifications given by the client. This is the TEST stage.
- Once your software product is ready , you may to do some code changes to accommodate enhancements requested by the client. This would be Maintenance stage.
- All these levels constitute the waterfall method of software development lifecycle.As you may observe, that testing in the model starts only after implementation is done.
- But if you are working in large project, where the systems are complex, its easy to miss out key details in the requirements phase itself. In such cases , an entirely wrong product will be delivered to the client. You will have to start a fresh with the project
- Or if you manage to note the requirements correctly but make serious mistakes in design and architecture of you software you will have to redesign the entire software to correct the error.
- Assessments of thousands of projects have shown that defects introduced during requirements & design make up close to half of the total number of defects
- Also, the costs of fixing a defect increases across the development life cycle. The earlier in life cycle a defect is detected, the cheaper it is to fix it. As the say, "A stitch in time saves a nine"
- To address this concern , the V model of testing was developed where for every phase , in the Development life cycle there is a corresponding Testing phase
- The left side of the model is Software Development Life Cycle - SDLC
- The right side of the model is Software Test Life Cycle - STLC
- The entire figure looks like a V , hence the name V - model
- You a find a few stages different from the waterfall model.
- These differences , along with the details of each testing phase will be discussed in later tutorial
- Apart from V model , there are iterative development models , where development is carried in phases , with each phase adding a functionality to the software.
- Each phase comprises of, its own independent set of development and testing activities.
- Good examples of Development lifecycles following iterative method are Rapid Application Development, Agile Development
- Before we close this software testing training a few pointers -
- You must note that, there are numerous development life cycle models. Development model selected for a project, depends on the aims and goals of that project
- Testing is not a stand-alone activity and it has to adopt with the development model chosen for the project.
- In any model, testing should performed at all levels i.e. right from requirements until maintenance.
Fundamental Principles of Software Testing
Video Transcript with Key Takeaways Highlighted:
- Consider a scenario where you are moving a file from folder A to Folder B.Think of all the possible ways you can test this.
- Apart from the usual scenarios, you can also test the following conditions
- Trying to move the file when it is Open
- You do not have the security rights to paste the file in Folder B
- Folder B is on a shared drive and storage capacity is full.
- Folder B already has a file with the same name, infact the list is endless
- Or suppose you have 15 input fields to test ,each having 5 possible values , the number of combinations to be tested would be 5^15
- If you were to test the entire possible combinations project EXECUTION TIME & COSTS will rise exponentially.
- Hence, one of the testing principle states that EXHAUSTIVE testing is not possible. Instead we need optimal amount of testing based on the risk assessment of the application.
- And the million dollar question is, how do you determine this risk ?
- To answer this lets do an exercise
- In your opinion, Which operations is most likely to cause your Operating system to fail?
- I am sure most of you would have guessed, Opening 10 different application all at the same time.
- So if you were testing this Operating system you would realize that defects are likely to be found in multi-tasking and needs to be tested thoroughly which brings us to our next principle Defect Clustering which states that a small number of modules contain most of the defects detected.
- By experience you can identify such risky modules.But this approach has its own problems
- If the same tests are repeated over and over again , eventually the same test cases will no longer find new bugs
- This is the another principle of testing called “Pesticide Paradox”
- To overcome this, the test cases need to be regularly reviewed & revised , adding new & different test cases to help find more defects.
- But even after all this sweat & hard work in testing, you can never claim you product is bug free. To drive home this point , lets see this video of public launch of Windows 98
- You think a company like MICROSOFT would not have tested their OS thoroughly & would risk their reputation just to see their OS crashing during its public launch!
- Hence, testing principle states that - Testing shows presence of defects i.e. Software Testing reduces the probability of undiscovered defects remaining in the software but even if no defects are found, it is not a proof of correctness.
- But what if , you work extra hard , taking all precautions & make your software product 99% bug free .And the software does not meet the needs & requirements of the clients.
- This leads us to our next principle, which states that-
- Absence of Error is a Fallacy i.e. Finding and fixing defects does not help if the system build is unusable and does not fulfill the users needs & requirements
- To fix this problem , the next principle of testing states that
- Early Testing - Testing should start as early as possible in the Software Development Life Cycle. so that any defects in the requirements or design phase are captured as well more on this principle in a later training tutorial.
- And the last principle of testing states that the Testing is context dependent which basically means that the way you test a e-commerce site will be different from the way you test a commercial off the shelf application
Summary of the Seven Testing Principles
Principle 1
|
Testing shows presence of defects
|
Principle 2
|
Exhaustive testing is impossible
|
Principle 3
|
Early Testing
|
Principle 4
|
Defect Clustering
|
Principle 5
|
Pesticide Paradox
|
Principle 6
|
Testing is context dependent
|
Principle 7
|
Absence of errors - fallacy
|
Introduction to Software Testing & its Importance : Tutorial 1
Video Transcript with Key Takeaways Highlighted:
- Software testing is a process used to identify the correctness, completeness, and quality of developed computer software. It includes a set of activities conducted with the intent of finding errors in software so that it could be corrected before the product is released to the end users.
- In simple words, software testing is an activity to check whether the actual results match the expected results and to ensure that the software system is defect free.
- Why is testing is important?
- This isChinaAirlines Airbus A300 crashing due to a software bug on April 26, 1994 killing 264 innocent lives
- Software bugs can potentially cause monetary and human loss, history is full of such examples
- In 1985,Canada's Therac-25 radiation therapy machine malfunctioned due to software bug and delivered lethal radiation doses to patients ,leaving 3 people dead and critically injuring 3 others
- In April of 1999 ,a software bug caused the failure of a $1.2 billion military satellite launch, the costliest accident in history
- In may of 1996, a software bug caused the bank accounts of 823 customers of a major U.S. bank to be credited with 920 million US dollars
- As you see, testing is important because software bugs could be expensive or even dangerous
- As Paul Elrich puts it - "To err is human, but to really foul things up you need a computer."
Subscribe to:
Comments (Atom)