انت هنا الان : شبكة جامعة بابل > موقع الكلية > نظام التعليم الالكتروني > مشاهدة المحاضرة
الكلية كلية تكنولوجيا المعلومات
القسم قسم البرامجيات
المرحلة 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
المادة المعروضة اعلاه هي مدخل الى المحاضرة المرفوعة بواسطة استاذ(ة) المادة . وقد تبدو لك غير متكاملة . حيث يضع استاذ المادة في بعض الاحيان فقط الجزء الاول من المحاضرة من اجل الاطلاع على ما ستقوم بتحميله لاحقا . في نظام التعليم الالكتروني نوفر هذه الخدمة لكي نبقيك على اطلاع حول محتوى الملف الذي ستقوم بتحميله .
|