انت هنا الان : شبكة جامعة بابل > موقع الكلية > نظام التعليم الالكتروني > مشاهدة المحاضرة

Unit testing

Share |
الكلية كلية تكنولوجيا المعلومات     القسم قسم البرامجيات     المرحلة 3
أستاذ المادة احمد خلفة عبيد العجيلي       30/06/2018 10:48:22
Introduction
I Before a software is delivered, the person building the software
should execute unit tests to verify that each unit functions
properly.
I All code is made up of a set of objects, functions, modules
or other non-trivial units. The purpose of unit testing is to
create a set of tests for each unit to verify that it performs
its function correctly.
I Programmers create suites of unit tests, where each test is
a small block of code which exercises a specific behavior of
one unit.
3 / 12
Unit concept
I The name “unit test" comes from the fact that each individual
unit of code is tested separately.
I In object-oriented languages like Java and C#, the units are
objects. In procedural languages like C, the units will correspond
to functions or modules
I A good test verifies many aspects of the software, including
(but not limited to) these attributes:
I The unit correctly performs its intended functions
I The unit functions properly at its boundary conditions
(like null or zero values)
I The unit is robust (it handles unexpected values and
error conditions gracefully)
4 / 12
Test frameworks
I The most common (and effective) way for programmers to
do unit testing is to use a framework which is a piece of
software that automatically runs the tests and reports the
results.
I A framework typically allows a programmer to write a set of
test cases for each unit.
I Unit testing frameworks are available for most modern programming
languages.
Language Framework name (URL)
Java JUnit (http://www.junit.org)
Visual Studio .NET NUnit (http://www.nunit.org)
C CUnit (http://cunit.sourceforge.net)
C++ CppUnit (http://cppunit.sourceforge.net)
Python PyUnit (http://pyunit.sourceforge.net)
Borland Delphi DUnit (http://dunit.sourceforge.net)
5 / 12
Unit Testing Example
I The examples here are individual test methods from a test
case object called testFeeCalculation
I Each test method requires an instance of the FeeCalculation
class, which is set up using this setUp() function:
public FeeCalculat ion feeCal culat ion ;
public void setUp ( ) {
feeCal culat ion = new FeeCalculat ion ( ) ;
}
I The first test simply verifies that the function has performed
its calculation and has generated the right result by comparing
the output to a known value:
6 / 12
Unit Testing Example (cont.)
public void t e s tTy p i c a lRe s u l t s ( ) {
Account accounts [ ] = new Account [ 3 ] ;
accounts [ 0 ] = new Account ( ) ;
accounts [ 0 ] . p r i n c i p a l = 35;
accounts [ 0 ] . rate = ( f loa t ) . 0 4 ;
accounts [ 0 ] . daysAct ive = 365;
accounts [ 0 ] . accountType =
Account .PREMIUM;
accounts [ 1 ] = new Account ( ) ;
accounts [ 1 ] . p r i n c i p a l = 100;
accounts [ 1 ] . rate = ( f loa t ) .035;
accounts [ 1 ] . daysAct ive = 100;
accounts [ 1 ] . accountType =
Account .BUDGET;
accounts [ 2 ] = new Account ( ) ;
accounts [ 2 ] . p r i n c i p a l = 50;
accounts [ 2 ] . rate = ( f loa t ) . 0 4 ;
accounts [ 2 ] . daysAct ive = 600;
accounts [ 2 ] . accountType =
Account .PREMIUM_PLUS;
f loa t r e s u l t = feeCal culat ion . calculateFee ( accounts ) ;
asser tEquals ( r e s u l t , ( f loa t ) 0.060289 , ( f loa t ) 0.000001) ;
}
This test passes. The call
to feeCalculation() with
those three accounts returns a
value of 0.060289383, which
matches the value passed to
assertEquals() within the
specified tolerance of .000001.
The assertion does not cause a
failure, and the test case completes.
7 / 12
Unit Testing Example
It’s important to test unexpected input. The programmer may
not have expected feeCalculation() to receive a set of accounts
that contained no premium accounts.
public void testNonPremiumAccounts ( ) {
Account accounts [ ] = new Account [ 2 ] ;
accounts [ 0 ] = new Account ( ) ;
accounts [ 0 ] . p r i n c i p a l = 12;
accounts [ 0 ] . rate = ( f loa t ) .025;
accounts [ 0 ] . daysAct ive = 100;
accounts [ 0 ] . accountType = Account .BUDGET;
accounts [ 1 ] = new Account ( ) ;
accounts [ 1 ] . p r i n c i p a l = 50;
accounts [ 1 ] . rate = ( f loa t ) .0265;
accounts [ 1 ] . daysAct ive = 150;
accounts [ 1 ] . accountType = Account .STANDARD;
f loa t r e s u l t = feeCal culat ion . calculateFee ( accounts ) ;
asser tEquals ( r e s u l t , 0 , 0.0001) ;
}
The expected result for this test is 0, and it passes.
8 / 12
Boundary Conditions
It’s not enough to just test for expected results. A good unit test
suite will include tests for boundary conditions, or inputs at the
edge of the range of acceptable values. There are many kinds
of boundary conditions, including:
I Zero values, null values, or other kinds of empty or missing
values
I Very large or very small numbers that don’t conform to expectations
(like a rate of 10000%, or an account that has
been active for a million years)
I Arrays and lists that contain duplicates or are sorted in unexpected
ways
I Events that happen out of order, like accessing a database
before it’s opened
9 / 12
Boundary Conditions
This unit test verifies that calculateFee() can handle an account
with a zero interest rate:
public void testZeroRate ( ) {
Account accounts [ ] = new Account [ 1 ] ;
accounts [ 0 ] = new Account ( ) ;
accounts [ 0 ] . p r i n c i p a l = 1000;
accounts [ 0 ] . rate = ( f loa t ) 0;
accounts [ 0 ] . daysAct ive = 100;
accounts [ 0 ] . accountType = Account .PREMIUM;
f loa t r e s u l t = feeCal culat ion . calculateFee ( accounts ) ;
asser tEquals ( r e s u l t , 0 , 0.00001) ;
}
10 / 12
Boundary Conditions
This test passes in an account with a negative principal (a calculator
was used to come up with the expected result by hand):
public void t e s tNe g a t i v ePr i n c i p a l ( ) {
Account accounts [ ] = new Account [ 1 ] ;
accounts [ 0 ] = new Account ( ) ;
accounts [ 0 ] . p r i n c i p a l = ??10000;
accounts [ 0 ] . rate = ( f loa t ) 0.263;
accounts [ 0 ] . daysAct ive = 100;
accounts [ 0 ] . accountType = Account .PREMIUM;
f loa t r e s u l t = feeCal culat ion . calculateFee ( accounts ) ;
asser tEquals ( r e s u l t , ??9.33265, 0.0001) ;
}
11 / 12
Duplicate reference
This test verifies that the software can handle a duplicate reference.
feeCalculation() takes an array of objects.
public void testDupl icateReference ( ) {
Account accounts [ ] = new Account [ 3 ] ;
accounts [ 0 ] = new Account ( ) ;
accounts [ 0 ] . p r i n c i p a l = 35;
accounts [ 0 ] . rate = ( f loa t ) . 0 4 ;
accounts [ 0 ] . daysAct ive = 365;
accounts [ 0 ] . accountType = Account .PREMIUM;
accounts [ 1 ] = accounts [ 0 ] ;
accounts [ 2 ] = new Account ( ) ;
accounts [ 2 ] . p r i n c i p a l = 50;
accounts [ 2 ] . rate = ( f loa t ) . 0 4 ;
accounts [ 2 ] . daysAct ive = 600;
accounts [ 2 ] . accountType = Account .PREMIUM_PLUS;
f loa t r e s u l t = feeCal culat ion . calculateFee ( accounts ) ;
asser tEquals ( r e s u l t , 0.0781316 , 0.000001) ;
}
12 / 12

المادة المعروضة اعلاه هي مدخل الى المحاضرة المرفوعة بواسطة استاذ(ة) المادة . وقد تبدو لك غير متكاملة . حيث يضع استاذ المادة في بعض الاحيان فقط الجزء الاول من المحاضرة من اجل الاطلاع على ما ستقوم بتحميله لاحقا . في نظام التعليم الالكتروني نوفر هذه الخدمة لكي نبقيك على اطلاع حول محتوى الملف الذي ستقوم بتحميله .
الرجوع الى لوحة التحكم