04UnitTesting

04UnitTesting - CS108, Stanford Winter 2010 Handout #4...

Info iconThis preview shows pages 1–3. Sign up to view the full content.

View Full Document Right Arrow Icon
CS108, Stanford Handout #4 Winter 2010 Young Unit Testing Handout written by Nick Parlante This handout introduces the ideas of unit testing and looks at using JUnit in Eclipse. Unit Testing Theory Software Engineering Challenges -- Complex Systems -- Bugs With Java, we're doing much better at code re-use and avoiding simple memory bugs. Large software systems remain hard to build and bugs are the main problem. Complexity -- it can be hard to make a change in a large system because it's hard to know if that change introduces a bug off in some other part of the system. Modularity helps address this problem, but it's still a problem. Unit Testing For each piece of "work" code -- a class or a method, pair the work code with some "unit test" code The unit test code calls the work code through its public API, calling it a few different ways and checking the results. Test code does not need to be exhaustive -- test code adds a lot of value even just hitting a few fairly obvious cases. Unit tests are a standard, maintained way to keep tests in parallel with the work code vs. the more one-off, informal way of doing some testing here and there manually The unit tests are more of an investment -- effort to build, but they improve development for the lifetime of the code. Fast Feedback -- A Boundary Unit test code is some work to install, but then it can be run very easily That the tests can be run easily guides your coding -- you get fast feedback as you try out ideas. The Unit tests are a like a boundary set up right at the edge of the space of correct operation of the code. Once the boundary is there and is run automatically, it provides quick valuable feedback when bugs are introduced. Why is a supertanker hard to steer? Because you turn the wheel, but don't get real feedback for many seconds. Unit tests are about tightening the feedback loop. It's easier to work in a system when you get instant feedback when you go over some boundary. High Quality Code We think about building lots of different types of code -- throw away code to production code (not everything needs to be super high quality of course) Historically, code was built to an intuitive "it appears to work when I run it" quality level With unit tests, we have the possibility to building code to a much higher quality level -- because we have the tests, and the infrastructure can run the tests constantly. The advantages multiply if we put together many components, each of which has its own unit tests Unit tests have raised the standard of what it means to build up a system of high-quality code
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
2 Test Driven Development (TDD) -- Workflow The "Test Driven Development" (TDD) style is a code development workflow that really emphasizes testing. Write the test code first, then write the work code and debug it until the tests pass. Every feature has corresponding unit test code. So a for a foo() method, we have test code that calls foo()
Background image of page 2
Image of page 3
This is the end of the preview. Sign up to access the rest of the document.

Page1 / 7

04UnitTesting - CS108, Stanford Winter 2010 Handout #4...

This preview shows document pages 1 - 3. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online