This preview shows page 337 - 339 out of 517 pages.
such a bug. There may be bugs in the interaction between your app and an external service such asTMDb; stubbing out the service so you can perform local testing might mask such bugs.Pitfall: Dogmatically insisting on 100% test coverage all passing (green) before you ship.As we saw above, 100% test coverage is not only difficult to achieve at levels higher than C1, but givesno guarantees of bug-freedom even if you do achieve it. Test coverage is a useful tool for estimating theoverall comprehensiveness of your test suite, but high confidence requires a variety of testing methods—integration as well as unit, fuzzing as well as hand-constructing test cases, define-use coverage aswell as control-flow coverage, mutation testing to expose additional holes in the test strategy, and so on.Indeed, in Chapter12we will discuss operational issues such as security and performance, which callfor additional testing strategies beyond the correctness-oriented ones described in this chapter.Fallacy: You don’t need much test code to be confident in the application.While insisting on 100% coverage may be counterproductive, so is going to the other extreme. Thecode-to-test ratioin production systems (lines of noncomment code divided by lines of tests of alltypes) is usually less than 1, that is, there are more lines of test than lines of app code. As an extremeexample, the SQLite database included with Rails containsover 1200 times as much test code asapplication codebecause of the wide variety of ways in which it can be used and the wide variety ofdifferent kinds of systems on which it must work properly! While there is controversy over how useful a
measure the code-to-test ratio is, given the high productivity of Ruby and its superior facilities forDRYing out your test code, arakestatsratio between 0.2 and 0.5 is a reasonable target.Pitfall: Relying too heavily on just one kind of test (unit, functional, integration).Even 100% unit test coverage tells you nothing about interactions among classes. You still need tocreate tests to exercise the interactions between classes (functional or module testing) and to exercisecomplete paths through the application that touch many classes and change state in many places(integration testing). Conversely, integration tests touch only a tiny fraction of all possible applicationpaths, and therefore exercise only a few behaviors in each method, so they are not a substitute for goodunit test coverage to get assurance that your lower-level code is working correctly. A common rule ofthumb used at Google and elsewhere (Whittaker et al.2012) is “70–20–10”: 70% short and focused unittests, 20% functional tests that touch multiple classes, 10% full-stack or integration tests.Pitfall: Undertested integration points due to over-stubbing.
As a current student on this bumpy collegiate pathway, I stumbled upon Course Hero, where I can find study resources for nearly all my courses, get online help from tutors 24/7, and even share my old projects, papers, and lecture notes with other students.
Temple University Fox School of Business ‘17, Course Hero Intern
I cannot even describe how much Course Hero helped me this summer. It’s truly become something I can always rely on and help me. In the end, I was not only able to survive summer classes, but I was able to thrive thanks to Course Hero.
University of Pennsylvania ‘17, Course Hero Intern
The ability to access any university’s resources through Course Hero proved invaluable in my case. I was behind on Tulane coursework and actually used UCLA’s materials to help me move forward and get everything together on time.
Tulane University ‘16, Course Hero Intern
Stuck? We have tutors online 24/7 who can help you get unstuck.
Ask Expert Tutors
You can ask
You can ask
You can ask
(will expire )