Page - 150 - in Programming for Computations – Python - A Gentle Introduction to Numerical Simulations with Python 3.6, Volume Second Edition

150 6 ComputingIntegralsandTestingCode 6.6 TestingCode 6.6.1 ProblemswithBriefTestingProcedures Previouslyin thisbook,ourprogramshavebeentested inverysimpleways,usually by comparing to hand calculations. For numerical integration, in particular, testing has so far employed two strategies. When the exact solution was available, we computedtheerrorandsawthatan increaseofngaveadecrease in theerror.When theexact solutionwasnot available,wecould (as in thecomparisonexampleof the previoussection) lookat the integralvaluesandsee that theystabilizedasngrew. Unfortunately, these are very weak test proceduresandnot at all satisfactory for claiming that thesoftwarewe haveproducedis correctly implemented. A Deliberate Bug To see this, we can introduce a bug in theapplication func- tion that callstrapezoidal: instead of integrating 3t2et3, we write “accidentally” 3t3et 3 , but keep the same anti-derivativex(t)= et3 for computing the error. With thebugandn=4, theerroris0.1,butwithoutthebugtheerroris0.2!It isofcourse completely impossible to tell if0.1 is therightvalueof theerror.Fortunately, in this case, increasingn shows that the error stays about0.3 in the programwith the bug, so the test procedurewith increasingn (andchecking that the error then decreases) points to aproblemin thecode. AnotherDeliberateBug Letus lookatanotherbug, this time in themathematical algorithm: instead of computing 12(f(a)+ f(b)) as we should, we “forget” the second 12 and write 0.5*f(a) + f(b). The error for n = 440,400 when com- puting ∫1.9 1.1 3t 2et 3 dt goes like 1400, 107, 10, respectively, which looks promising. The problem is that the right errors should be 369, 4.08, and 0.04. That is, the error should be reduced faster in the correct than in the buggy code. The problem, however, is that it is reduced in both codes, and we may stop further testing and believeeverythingis correctly implemented. UnitTesting Agoodhabit is to test smallpiecesofa largercodeindividually,oneata time. This isknownasunit testing:A(small)unitof thecode is identified,so thata separatetest for thisunitcanbemade.Theunit testshouldbe“stand-alone”in the sense that it can be run without the outcomeof other tests. Typically,one algorithmin scientific programsis considereda unit.The challengewith unit tests innumericalcomputing, is todealwith numericalapproximationerrors. A fortunate side effect of unit testing is that the programmer is forced to use functions to modularize thecode into smaller, logicalpieces.