Project 4, CSC 202
Wow! Week 10 already! Boy, time flies.
In this assignment, it’s time to take what you’ve learned, and see how it applies in real-world projects. Specifically, you’ll be taking a look at the source code of an existing open-source tool, to see how data structures are used in larger projects.
Specifically, you’ll be looking at the source code of a project that is widely used: the coverage.py coverage tester for python.
1 What is a Coverage Tester?
There are many ways of assessing how good a test suite for a program is. One way is to test the "coverage" of the test suite. That is: running the test suite will cause some fraction of the code under test to be executed. "Code Coverage" is a measure indicating what fraction of the code under test is executed.
So, for instance, if I wrote a program of 10,000 lines, and running my test suite evaluated 8,500 lines of that program, we would say that my test suite has 85% coverage.
The coverage.py tool is a python library that takes a program and a test suite, and rewrites the program so that it keeps track of which parts of the program are executed, and then runs the test suite to measure the coverage.
2 Teams
This project has a time limit; your team should spend no more than four hours working on it, including the writeup.
The total writeup for this project is limited to 800 words.
3 Procedure
3.1 Before Examining the Code
Before you begin, you should spend a few minutes thinking about what data structures you’d be likely to need if *you* were implementing a coverage tester. Write up your results (what data structures you think you’d need, what they’d be used to represent) in about 150 words.
3.2 Initial Code Examination
Next, download the source code. Take a look at the files in the project, try to get a feel for what the structure of the source tree is, what files appear in what directories. Is there a useful README? Is most of the project source code? How much of the source code is for testing? Use a tool like wc to count lines and words and get a sense of how big each part of the project is.
Next, take a look at two randomly chosen files in the test subdirectory, and five randomly chosen files in the coverage subdirectory. For each one, try to figure out what it does. Which is more valuable: the code, or the comments?
Write up your findings in about 200 words, including a one- or two-sentence summary for each source file you look at.
3.3 Detailed Code Examination
Pick a file that you think might be likely to make use of data structures in an interesting way. You should probably be guided by your initial speculation about how data structures might be used in this project. Read through this file carefully, and try to understand how it works, and how it uses data structures. If the file that you’ve chosen turns out not to make interesting use of data structures, you’re welcome to choose another. If the use of a particular data structure is spread across two files, you can look at both of them, but try not to get wound up in reading a whole bunch of files.
If possible, narrow down to a particular data structure. Take a look at where it’s created, where it’s used, and where it’s mutated (if applicable). Where do the values of this data structure flow?
Write up your findings in about 300 words.
3.4 Summary
Finally, take some time to reflect on the quality of the code in the project. Is it readable? Is it clear what every function does? How are comments used? How would you feel about maintaining or updating this code? How does this code compare to your own code? You’re welcome to answer other questions than these, and comment on anything you found particularly noteworthy.
Write up your findings in about 150 words.
3.5 Are you done?
No! You’re not done. Now you need to go back and edit what you’ve written. Did you write too much? That’s fine, it just means that you need to go back and tighten things up, polishing your text until it shines.
4 Writeup Formatting
Format your writeup as a text file. You should use standard Markdown format, where section titles are formatted using a single leading hash. The template repository contains an example writeup.md file.
5 Source Code
Here’s the link to the source code for the coverage.py tool.
6 Submitting your writeup
Submit your writeup by pushing to a project repository created using the invitation link above. Only one team member needs to submit. If multiple students in a group submit, I will choose the one with the later given commit date.