Please note: In order to keep Hive up to date and provide users with the best features, we are no longer able to fully support Internet Explorer. The site is still available to you, however some sections of the site may appear broken. We would encourage you to move to a more modern browser like Firefox, Edge or Chrome in order to experience the site fully.

Design Driven Testing : Test Smarter, Not Harder, PDF eBook

Design Driven Testing : Test Smarter, Not Harder PDF

PDF

Please note: eBooks can only be purchased with a UK issued credit card and all our eBooks (ePub and PDF) are DRM protected.

Description

In this chapter we illustrated how to drive unit tests from a software design, identifying test scenarios in a systematic way that ensures the code is covered in all the right places.

We also illustrated the use of "stunt services" and mock objects to isolate the code being tested; finally, we discussed driving unit tests deeper into algorithmic code that may benefit from finer-grained testing.

Is there a way to get 95% of the benefit of the comprehensive unit testing we did in this chapter with significantly fewer tests?

In the next chapter, we'll show how to do exactly that with controller tests.

As you'll see, unit tests do have their place, but controller tests can often represent a smarter, more structured approach to application testing. 136 C H A P T E R 6 ? ? ? Conceptual Design and Controller Testing As you saw in Chapter 5, unit testing doesn't have to involve exhaustively covering every single line of code, or even every single method, with tests.

There's a law of diminishing returns-and increasing difficulty-as you push the code coverage percentile ever higher.

By taking a step back and looking at the design on a broader scale, it's possible to pick out the key areas of code that act as input/output junctures, and focus the tests on those areas.

Information

Other Formats

Information