Docsity
Docsity
Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity

Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan

Guidelines and tips
Guidelines and tips
Sell on Docsity
Sell on Docsity
Docsity AI
Docsity AI
Log inSign up

Prepare for your exams

Study with the several resources on Docsity

Find documents

Prepare for your exams with the study notes shared by other students like you on Docsity

Search for your university

Find the specific documents for your university's exams

Docsity AINEW

Summarize your documents, ask them questions, convert them into quizzes and concept maps

Explore questions

Clear up your doubts by reading the answers to questions asked by your fellow students

Earn points to download

Earn points by helping other students or get them with a premium plan

Share documents
download point icon20 Points

For each uploaded document

Answer questions
download point icon5 Points

For each given answer (max 1 per day)

All the ways to get free points
Get points immediately

Choose a premium plan with all the points you need

Study Opportunities

Choose your next study program

Get in touch with the best universities in the world. Search through thousands of universities and official partners

Community

Ask the community

Ask the community for help and clear up your study doubts

Free resources

Our save-the-student-ebooks!

Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors

Testing, Debugging and Tools - Lecture Slides | CMSC 433, Exams of Programming Languages

University of MarylandProgramming Languages
Prof. William Pugh

Material Type: Exam; Professor: Pugh; Class: PROG LANG TECH & PDGMS; Subject: Computer Science; University: University of Maryland; Term: Spring 2003;

Typology: Exams

Pre 2010

Uploaded on 07/30/2009

koofers-user-jfy
koofers-user-jfy 🇺🇸

10 documents

1 / 7

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
CMSC 433 – Programming Language
Technologies and Paradigms
Spring 2003
Testing, Debugging, and Tools
February 13, 2003
The Testing Environment
•Want to create a scaffold for executing tests
–Code infrastructure to run tests and check output
•Many benefits
–Can automate testing process
–Useful for regression testing
•But, can take some time to implement
Testing Environment Components
•A user to generate input for tested component
•An oracle for verifying the results are correct
•These two may be combined into a single system
Unit Testing with Junit
•Testing environment for writing black-box tests
–Write special TestCase classes to test other classes
–Several ways to use/set up test cases
•Can be downloaded from
–http://www.junit.org
pf3
pf4
pf5

Partial preview of the text

Download Testing, Debugging and Tools - Lecture Slides | CMSC 433 and more Exams Programming Languages in PDF only on Docsity!

CMSC 433 – Programming Language

Technologies and Paradigms

Spring 2003

Testing, Debugging, and Tools

February 13, 2003

The Testing Environment

• Want to create a scaffold for executing tests

  • Code infrastructure to run tests and check output

• Many benefits

  • Can automate testing process
  • Useful for regression testing

• But, can take some time to implement

Testing Environment Components

• A user to generate input for tested component

• An oracle for verifying the results are correct

• These two may be combined into a single system

Unit Testing with Junit

• Testing environment for writing black-box tests

  • Write special TestCase classes to test other classes
  • Several ways to use/set up test cases

• Can be downloaded from

  • http://www.junit.org

Junit Philosophy

• Iterative, incremental process

  • Write small black-box test cases (as needed)
  • Test-as-you-go
    • i.e., after changes, when new method added, when bug identified

• Junit test cases must be completely automated

  • No human judgment
  • Easy to run many of them at the same time

• Goal: lots of bang for the buck

  • Even simple tests can find many bugs quickly

TestCase Example with Lists

public class ListTest extends TestCase { public void testAdd() { LinkedList l = new LinkedList(); Object o = new Object(); l.add(o); assertTrue(l.contains(o)); } public void runTest() { testAdd(); } public static void main(String args[]) { TestResult result = (new ListTest().run()); if (!result.wasSuccessful()) { System.out.println(“Doh!”); } } Create objects Perform test/ check result

Junit Components

• Test cases (class TestCase )

  • Individual tests
  • Can reuse test case setup (optional)

• Test suites (class TestSuite )

  • Test case container

• Test runner (various classes)

  • Executes test suites and presents results

Each test has three 3 parts

• Code that creates test objects

  • Create a subclass of junit.framework.TestCase

• Code that executes the test

  • Override the method runTest() (which executes the test)

• Code that verifies the result

  • e.g., use junit.framework.assertTrue() to check results

(throws exception is test fails)

Test Suites (cont’d)

• You can also create test suites more easily:

public static Test suite() { TestSuite suite = new TestSuite(); suite.addTest(new ListTest(“testAdd”)); suite.addTest(new ListTest(“testPushPop”)); return suite; }

• Or simply:

public static Test suite() { return new TestSuite(ListTest.class); }

Test Runner

• To execute test suite, pick a class:

  • For graphical display
    • junit.awtui.TestRunner TestCaseClass or
    • junit.swingui.TestRunner TestCaseClass
  • For textual display
    • junit.textui.TestRunner TestCaseClass

• Or run from within your own code:

public static void main(String args[]) {

junit.textui.TestRunner.run(suite());

Running Tests Easily

• Put import junit.framework.*; at top of file

• Test runners will use static suite() method

• If no suite() method, suite selected automatically

  • Every method that is public , returns void , takes no

arguments, and begins with “test”

• Then use junit.*.TestRunner TestClass

  • Or use DrJava

IDEs

• IDE: Interactive Development Environment

  • Editor
    • Usually with some nice syntax coloring, indentation features
  • Compiler
    • Errors sorted, displayed nicely; easy to see corresponding code
  • Debugger
    • Closely watch/change execution of source code
  • Etc...
    • Testing, search, code transformations, ...

• Examples: DrJava, NetBeans, Eclipse, Visual

Studio, emacs

Dr. Java

  • Light-weight IDE
  • Editing
    • Syntax coloring, auto-indent, brace matching
  • Testing
    • Integrates with Junit testing framework
      • Uses suite() or auto-generated suite
    • Interaction panel allows interactive method invocations
  • Debugging
    • Integrates with Java debugger
    • Interactions panel also useful

Debugging

• My program doesn’t work: why?

• Use the scientific method:

  • Study the data
    • Some tests work, some don’t
  • Hypothesize what could be wrong
  • Run experiments to check your hypotheses
    • Testing!
  • Iterate

Starting to Debug

• What are the symptoms of the misbehavior?

  • Input/output
  • Stack trace (from thrown exception)

• Where did the program fail?

• What could have led to this failure?

• Test possible causes, narrow down the problem

Checking that Properties Hold

• Print statements

  • Check whether values are correct
    • E.g., look at value of i to check if i > 0
  • Check whether control-flow is correct
    • E.g., see if f() is called after g()

• Automatic debugger

  • Allows you to step through the program interactively
  • Verify expected properties
    • Don’t need to put in print statements and recompile
  • Use as part of testing

Defensive Programming

• Assume that other methods/classes are broken

  • They will mis-use your interface public Vector(int initialCapacity, int capacityIncrement) { super(); if (initialCapacity < 0) throw new IllegalArgumentException( "Illegal Capacity: "+ initialCapacity); ... }

• Goal: Identify errors as soon as possible

Avoiding Errors

• Codify your assumptions

  • Include checks when entering/exiting functions,

iterating on loops

• Test as you go

  • Using Junit
  • Using the on-line debugger

• Re-test when you fix a bug

  • Be sure you didn’t introduce a new bug

• Do not ignore possible error states

  • Deal with exceptions appropriately