This is not the current offering of the course. You may want the next offering at https://ucsd-cse15l-f22.github.io/, or scroll down for the winter 2022 material.

Week 3

Week 3 – Incremental Programming and Debugging

Table of Contents

Due Dates & Links

Due This Week

  • Quiz 3 - Due 11:59am January 19, 2021

To Watch/Read

Notes from Class

1pm Wed

2pm Wed

3pm Wed

Lab Tasks

As usual, we provide the lab tasks ahead of time, but they might change or update before lab starts; these aren’t guaranteed to be in their final version until lab starts at 1pm on Wednesday.

This week’s lab will focus on the process of testing and debugging. There are lots of ways to go about testing and debugging programs! We will study several in this course.

Today, we will focus on the process of incremental development, in a style similar to test-driven development.

Each lab group will work collaboratively on a programming problem with known bugs. The sample programing prompt we will be working with is:

Write a program that takes a markdown file as a command line argument and then prints out all of the URLs of the links (but not of images) in that file.

This might be useful for building a references/citations page for a website, for example.

Parts of this example were inspired by the first HTML-parsing example in The Debugging Book.

Getting Started

For reference, here is the video from the quiz:

https://youtu.be/_y9hkrN9k3w

Answer the following questions:

  • How many times did the programmer use the internet to look up how to do something?
  • Around what was the largest number of lines of code written in between runs of the program?
  • Around how many times did the programmer use autocomplete on a variable name? How many typos do you think this helped avoid?

Write the answers to these questions in your shared notes document.

Getting and Running the Code

Everyone in your group should make a fork of this repository:

https://github.com/ucsd-cse15l-w22/markdown-parse

The fork button is on the upper right:

This makes a copy of the repository on your Github. Then, clone the repository that you forked (not the original) using Github Desktop, and open it in Visual Studio Code.

If you have Java installed on your computer, make sure you can run it using the commands from the video. If you don’t, use commands to copy the code to your remote CSE15L account and run the program there.

Make sure everyone can run the examples from the video.

Then, add print statements, look up online, or use your own reasoning as a group to answer the following questions:

  • How many different values does currentIndex have when the program is run on the given example? What are they?
  • What is the purpose of the second argument to indexOf? What would be different if it wasn’t provided?

Write the answers to these questions in your shared notes document.

Finding a Breaking Test

The provided code gives reasonable results for the single test the programmer tried. The programmer should be satisfied with a good start, but not satisfied with a single test. We will take over from where they left off to test and complete the program.

Create a new markdown file that tests a different use of links than in the original. Test the program on that file. Discuss among your group what it means to test something different. Try running your new test. What happens? Did it succeed or not?

Keep trying different content in markdown files until you get something that has incorrect behavior (an error, an infinite loop, prints the wrong URLs, etc). As soon as you see incorrect behavior, stop.

Make a commit with the new test file; there should be no edits to the code file. Copy/paste the unexpected output into the commit message, then make the commit and push. (If you cloned the original repository instead of your fork, you might get an error that you cannot push to it; if you do, take the time now to double-check that you cloned your fork. If you can’t push for some reason, make sure to come to office hours or figure it out on your own later; you can still make all the commits for the remainder of the lab).

Include links to all of the individual commits on Github of this new test in your notes document (screenshot instead if you had issues pushing).

Discuss: Why bother making a commit at this point? What benefit might that have in the future? How might it help a staff member who is answering your question on Piazza? Give at least three positive examples in the notes document.

Improving the Program

Discuss as a group – why is the program not behaving as expected on the test file you wrote? How could you fix it?

Work as a group on fixing the program so that:

  • The original test still has the same output (the one the programmer initially tried)
  • The broken test you wrote has correct output

Remember – this means you need to keep testing on the original test and on the new one you wrote, until both work.

When you’ve updated the program to work on both of these cases, make a commit that should have just the changes to the .java file required to make it pass.

Include the commit in your notes document so everyone can refer to it.

Repeating the Process

Repeat this process for at least 2 more test files that fail for different reasons:

  • Create the test file that fails
  • Commit/push it with the failing output in a commit message
  • Fix the program so it succeeds on that test, and on all previous tests
  • Commit/push the fix

Here are some hints for tests you might try:

  • Try a file with an image reference
  • Try a file that starts with a link
  • Try a file that ends with a link
  • Try a file with a link in the middle
  • Try a file with no links
  • Try a file that uses [] but not ()
  • Try a file that uses () but not []
  • Try a file that uses [] and (), but very far apart in the file

Discuss: What techniques did you use to figure out how to fix the program? Did you insert print statements anywhere? Did someone in your group suggest an idea that didn’t occur to others to try? What was it? Include a summary of what your group did in order to fix the program in each case.

Write in notes: Include links to the commits described above for at least one group member’s repository (that way everyone can find it later).