Held: Friday, 5 September 2014

Back to Outline 04 - An Overview of Java. On to Outline 06 - Classes and Objects.

Summary

We begin to explore the process of unit testing, focusing on the JUnit framework.

Related Pages

• Reading: Unit Testing
• Lab: Unit Testing
• EBoard 5 (Source 5) (HTML 5)

Overview

• A few thoughts on testing.
• An example: Testing exponentiation.
• A few notes on test-driven development.

Administrivia

• New lab partners!
  • Take a playing card.
  • Find someone with the same playing card value.
• You can view notes from yesterday's review session
• Since it's a weekend, a few reminders.
  • Decide what you want and what you feel comfortable with.
  • And please, if you drink, please drink responsibly.
• Sorry for the confusion about unit tests on HW3. We'll cover how to get it set up today.
• For department planning:
  • How many of the second-year students in this class are planning to be CS majors?

Making Eclipse Use Java 8

For some reason, not everyone's Eclipse is using Java 8. (You can tell which version it's using when you create a new project.) Here are some instructions that should get it working.

• Window > Preferences > Java > Installed JREs
• Add > Standard VM > Next
• Enter /opt/jdk1.8.0_11 for the JRE home.
• Enter jdk1.8.0_11 (or something similar) for the Name
• Click the checkbox next to that JRE.
• Click OK

Upcoming Work

• HW 3 due Tuesday.
• Daily lab writeup: http://bit.ly/207writeup
  • We'll talk a bit about these.
• Readings for Monday:
  • Writing Your Own Classes
  • Standard Object Methods

Extra Credit Opportunities

• Note: Please send a short (one paragraph) reflection on any extra credit activity you attend. And reflect, don't summarize.

Academic

• CS table immediately after class: The Mythical Man-Month.
• Convo next Wednesday at noon. "Limiting Armed Drone Proliferation" by Micah Zenko, the Douglas Dillon fellow in the Center for Preventive Action at the Council on Foreign Relations and vice chair of the World Economic Forum Global Agenda Council on Terrorism.
  • Sam's comments on the value of convo
• Any other event in the Rosenfield Drones program.
• CS Extra, Thursday, September 11: Ajuna Kyaruzi '17 on being a SysAdmin

Peer Support

• Men's Soccer, Saturday, 3pm vs Aurora

Miscellaneous

• Second-year students get extra credit for doing the second-year science retreat on Sept. 20.
  • Email went out yesterday. Let me know if you didn't get it.

A Brief Introduction to Unit Testing

• How do you know your code works?
• Typically, you run "experiments" on your code ("When I give this input, I should get this output. Do I?")
  • Many people call these "tests", but I try to distinguish the two.
• But experiments are not a great approach.
  • A human is doing the comparison; that's a job better suited to the computer.
  • You are unlikely to document your experiment (or at least your expected output), which means that you'll have to regenerate it latter.
  • You are likely to have to build a framework to do your experiments.
  • Looking at output by hand means that you generally won't conduct many experiments.
• What's the alternative? Tests.
  • A test typically checks whether a function has an expected output on a given input (just like an experiment, except that the computer does the comparison).
  • A test is represented by executable code. Running it again is easy (and it's often self-documenting).
  • Tests generally have only one of two outputs: Success or "expected A, got B".
• Since the computer does most of the work, and since the tests persist, you are comfortable writing bigger tests and running them more often.
• In courses, you can share tests, so your code gets challenged by multiple perspectives.
• It takes a long time to become good at writing tests. We'll develop those skills across the semester.
• In Java, JUnit is one of the popular frameworks for doing this kind of testing. And it's nicely integrated into Eclipse.
  • I'm not going to discuss JUnit because you'll learn more writing test code than watching me write test code.

Sam's Quick and Dirty Reasons for Unit Testing

• You're going to check your code anyway; why not capture what you want to check?
• Writing the tests helps you think about what you really want the procedure to do, particularly in edge cases.
• You can do many more tests by code than you can do by hand.
• Note: To differentiate checking code by hand and checking by code, I try to use the terms "experiment" for "by hand" and "test" for "by code".

An Example: Testing Exponentiation

• It takes time to develop the skill of writing good tests.
• Let's start by thinking together about one test suite.
• What tests would you write for a function that computes x^n, where x and n are integers?

Test-Driven Development

• Unit testing is a key aspect of many agile software development methodologies.
• Often, unit testing is a key aspect of test-driven development (TDD).
• There are two general approaches to TDD.
  • Repeatedly write a test and make your procedure meet that test until you can't think of any more tests to write.
  • Write a lot of tests up front and then write your procedure. Then write a few more to stress your particular implementation (or because you've learned something).
• I prefer the latter. I find that if you write a lot of tests in advance, you have a better sense of what the procedure is supposed to do.

Lab: Unit Testing

Do the lab.

Be prepared to reflect.