Testing, Static Analysis, and Continuous Integration (Cont’d)

Fall 2026

1

Roadmap

• This Thursday (10/2): we will be reviewing the expectations for Project 1, and ensuring that everyone has their first task.
• Next Tuesday - Fall Break!
• Next Thursday (10/8): Midterm Exam review
• Please practice your programming over the break (see quicklinks on the left) on course website.
• Next Tuesday (10/13): Midterm Exam (paper-based, completed in class).

Introduction to the Idea of “Shifting Left”

These three Google chapters encompass different ways of “shifting left.” Why?

1. Chapter 11. Testing Overview
2. Chapter 20. Static Analysis (skim)
3. Chapter 23. Continuous Integration (skim)

Outline

1. Testing review
2. Static Analysis
3. Continuous Integration
4. Intro to Project 1

Outline

1. Testing review
2. Static Analysis
3. Continuous Integration
4. Intro to Project 1

Testing: Questions about Lab 6

1. How did you go about testing your code?
2. How confident are you that your tests cover all of the possible cases?
3. What were the pros and cons of using a framework (Mocha or Pytest / unittest) over rolling your own test framework?
4. What kinds of tests did you write (small, medium, or large)?

Outline

1. Testing review
2. Static Analysis
3. Continuous Integration
4. Intro to Project 1

Static Analysis: Discussion Questions

Some static analysis questions you should be able to answer by the end of this unit:

1. What is the difference between an interpreted and a compiled language?
2. What languages are interpreted? What languages are compiled?
3. What do we mean by “static”?
4. What are some examples of static analysis tools?
5. What are some of the benefits of doing static analysis?
6. What are some of the challenges / limitations of static analysis?

What are some examples of static analysis tools?

​

• Autoformatters – Focus on formatting code automatically, enforcing style consistency (e.g., Black for Python, Prettier for JavaScript)
• Linters – Analyze code for possible errors, style violations, or inefficiencies, but typically leaves the code unchanged (e.g., Flake8 for Python, eslint for JavaScript)
• Security / Dependency tools – scripts that identify deprecated dependencies or security vulnerabilities (usually written in-house).

What are some of the benefits of static analysis?

Your thoughts here…

What are some of the drawbacks / tradeoffs os static analysis?

• Your answers here

Outline

1. Testing review
2. Static Analysis
3. Continuous Integration
4. Intro to Project 1

Continuous Integration (CI): Discussion Questions

Some continuous integration questions you should be able to answer by the end of this unit:

1. What is continuous integration?
2. What are some of the key benefits and headaches (i.e. tradeoffs) of continuous integration?
3. Can you still use continuous integration if you’re working on a really big feature that’s not ready for prime time?
4. What happens in the "presubmit" phase?
5. What is release candidate testing? How is it similar / different from the "presubmit" phase?

1. What is Continuous Integration?

“Continuous Integration, or CI, is generally defined as “a software development practice where members of a team integrate their work frequently [...] Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible.”

​

Goal of CI: �To automatically catch problematic changes as early as possible.

2. What is “Shifting Left”

​

The cost of a bug increases exponentially the later it is caught (has it already been deployed, or are we still in early development). Therefore, the more tools you have in place to catch bugs earlier in the development process, the better!

5, 6. What happens in these phases?

What kinds of testing / validation happens in…

1. Presubmit (before the code is merged into main): Is this change safe to add to the main branch?
2. Post-submit (after the code is merged into main): Does the repository as a whole still work with this change in it?
3. Release candidate: Is this assembled version actually ready to ship?

3. What are some of the benefits and headaches (i.e. tradeoffs) of continuous integration?

Pros:

​

Cons:

• ​

Outline

1. Testing
2. Static Analysis
3. Continuous Integration
4. Intro to Project 1

Project 1: What does this app need to do?

For your first project, you are going to create a command line tool to replicate aspects of the UNCA Course Search app. What are the specific needs that your tool need to support:

• A way to download the UNCA data file from the Internet (JSON)
• Filter: ??? course name, number, instructor, credit hours, department, time of day, async, meeting type, open / closed. Based on what you need to graduate.
• A way to retrieve data
• A way to add / remove / update (CRUD) to the schedule
• A way to view the data

Project 1: What does this app need to do?

• Searching for classes for graduation / registration. Connect to grad plan <> registration.

Activity: On Your Own (10 mins)

​

• Take out a piece of paper (or open a text editor)
• Write down all of the classes you will need to create to build your course lookup app.
• For each class, think about the data and methods that will be needed.
• Think about how you would make this functionality testable.
• Think about what you could do today to…
• Make this project maintainable over time?
• Minimize merge conflicts

Activity: With Your Groups (10 mins)

​

• Discuss your designs with one another?
• What was similar or different?

When you’re done, you’ll share out with the class.

Oct. 1

The Starter Code

• After Sarah adds you as a contributor, clone the repo (look back to previous homeworks if you don’t remember how to do this):�https://github.com/csci338/project01-fall2026/
• Read the README.md and follow the configuration / installation instructions.
• When you’re done, we’re going to walk through some of the code files.

UNCA Class Search

What we’re building: A terminal app to search UNCA courses, built by our whole class.

• Search and filter real course data: by title, department, credits, days, instructors and more.
• Build a class schedule: add and remove courses, see total credits and time conflicts.
• Learn a new library called Textual: for building interactive apps in the terminal using python.
• The starter already runs. Try it: poetry run unca-class-search

Code Walkthrough: Big picture

• Follow one search. A user types "data" and presses Enter. Which files does the request pass through, in order, before rows appear in the table? (filter_bar.py → app.py → search.py → filters/title.py → results_table.py)
• What is each file's one job? Pick three files. Can you say what each one does in a single sentence, without using the word "and"?

Code Walkthrough: Data

• Why turn the JSON into Course objects instead of passing the raw JSON around? What would every filter have to do differently? (data.py, course.py)
• Why can't a function change a Course? What could go wrong if a filter could edit the course it was checking?

Code Walkthrough: Filters

• Why do all filters have the same signature, (course, value) -> bool? What would be harder if each filter took different arguments? (search.py)
• What should a filter do when the course data is unknown? For example, "credits = 3" but the course has no credits listed.

Code Walkthrough: The User Interface

• Why does a widget send a message instead of calling the search function itself? (filter_bar.py)
• Why does loading run in the background? What would the user see if it didn't?
• If the download fails, what should the app do? Who decides, and which file makes that decision?
• How do you know your function works without starting the whole app? (make_course, tests/)

Working together and changing the code

• Fifteen people are building this at the same time. What makes it possible to do that without editing the same file?
• Add a new filter. Which files do you change, and which files do you not touch? What does that tellyou about the design?
• How do you know your function works without starting the whole app? (make_course, tests/)

Tips

​

• Single Responsibility Principle: A class should only have one job.
• DRY Principle: Don’t repeat yourself.
• Optimize for code readability rather than for performance: Why?

Make it correct,� make it clear,� make it concise,� make it fast.� In that order.

• Delete unused code

https://vedantsopinions.medium.com/software-engineering-rules-of-thumb-63060ca51b94

Tips

​

• Be deliberate with your naming – Name your classes, methods, class variables and even local variables very semantically.
• Change one thing at a time – You don’t want a pull request that’s 1,000 lines long. Nightmare to review. Rather, make smaller PRs that have changes that are clear and easy to review / understand.
• Write “dumb code” –
• “Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”
• Beyoncé Rule – put a test on it; write testable code

https://vedantsopinions.medium.com/software-engineering-rules-of-thumb-63060ca51b94

How we'll build it: small pieces, in parallel

• Each of you owns one small, independent piece: a set of filters, a sort, a schedule check, or a screen widget.
• Your piece has its own files and its own tests, so you never wait on classmates or edit the same file.
• Everyone follows the same agreements: the function signatures and rules in docs/contracts.md.
• Your ticket is your assignment: it names the files, functions, and behavior.
• Then we connect the finished pieces into the Textual app.

How the work flows, and where to start

• Every change follows the same process: branch, write tests, write code, run the checks, open a pull request, describe it well.
• Three automatic checks: pytest, Black (formatting), and Flake8 (lint). CI runs them on every PR.
• I review every pull request. Expect comments, and respond to them.
• Three rounds: round 1 a first feature, round 2 a second feature or widget, round 3 connecting features to the app (for those who finish).
• Start today: install the project, run the tests, then do the warmup exercise (WARMUP.md) so the workflow isn't new when your ticket arrives.