CPSC 329 Review Information — Exam 1

Exam 1 is a written in-class (one hour) exam covering material from the first 3.5 weeks of the course: software development foundations, testing and verification, teamwork and professional practices, software construction practices. Expect short answer questions focusing on foundational knowledge and underlying concepts. Some questions focus on definitions and recall while others may ask you to apply that knowledge to a particular scenario.

Answers should be short — generally 1-3 sentences, or 1-2 sentences per part for a question with several parts. A list rather than complete sentences is fine where appropriate. Time is limited, so don't write more than necessary!

The topics covered on the exam are listed below. The items under "Self check" are study goals — examples of the kinds of things you should be able to do, rather than actual exam questions or a complete list of what the exam might ask. As a starting point for studying, try to explain each topic without notes (including an example of your own where appropriate) and then answer the associated self check items. Finally, formulate (and then answer) your own questions about each topic. As a pacing guide, you should be able to start writing answers for definition/recall questions right away and "apply to a scenario" questions after a minute or two of thinking.

Foundations: Software Development

Software development process topics:

• Lifecycle phases and how they relate
• Approaches to software development: waterfall, iterative and incremental

Self check:

• Name and describe the standard phases of a software development lifecycle.
• Describe how requirements, design, construction, testing, and maintenance relate to one another across a project's life.
• Contrast iterative/incremental development with a pure waterfall approach, including the strengths and weaknesses of each.

Testing and Verification

Testing topics:

• Why we test; the cost of finding bugs late
• Verification vs. validation
• Levels of testing
• What makes a good test
• Test plans
• Edge cases
• Test coverage
• Testing in proportion to risk
• Integration testing approaches
• Black-box and white-box testing
• Test doubles: purpose and types (stubs, fakes, mocks)
• Designing for testing
• Test-driven development: red, green, refactor
• Benefits and limits of TDD

Debugging topics:

• The debugging mindset and strategies for finding bugs
• Tools: print statements, the debugger, assertions, logging
• Choosing a debugging tool

Self check:

• Explain why a program that runs without errors may still be incorrect and how the cost of a bug depends on when it is found.
• Distinguish verification from validation and classify a given activity or failure as one or the other.
• Compare the different levels of testing and identify the appropriate one for a given scenario.
• Describe the components and characteristics of a good test.
• Given a test, identify weaknesses in how it is written.
• Explain the purpose and contents of a test plan and the advantages of writing one before coding.
• Explain what an edge case is and identify edge cases worth testing given a method's specification.
• Explain how risk should guide how much testing a piece of code receives, and apply it to decide which of a given set of methods most warrant dedicated tests.
• Compare top-down, bottom-up, and sandwich integration and explain the roles of drivers and stubs.
• Distinguish black-box from white-box testing and describe how each would be used to design tests for a given method.
• Explain why and when a dependency would be replaced by a test double and distinguish stubs, fakes, and mocks.
• Explain what makes code testable and identify design choices that make code hard to test.
• Explain some limitations of testing — what passing tests and high coverage do and do not tell you.
• Describe the steps of test-driven development and the purpose of each step.
• Evaluate the benefits and limitations of TDD for a given task.
• Describe strategies for locating a bug, including what to do when stuck.
• Compare print statements, the debugger, assertions, and logging and choose an appropriate tool for a given situation.

Teamwork and Professional Practices

Teamwork topics:

• Advantages and risks of teams
• Strategies for managing the risks
• Effective communication
• Conflict: causes of team conflict, responses, collaborating well
• Cooperative programming: pair programming, swarming
• The cost of mistakes
• Code review: purpose, what to check, giving and receiving feedback
• Effort estimation
• Working with unfamiliar code

Version control topics:

• Why use version control
• The Git mental model
• Git terminology: repository (local vs remote), snapshot, history, working directory, staging area, commit, revert/reset, branch, merge, merge conflict, push, pull, pull request
• Commit hygiene
• Workflows: solo, team, resolving conflicts
• Branching strategies: feature branching, trunk-based development; GitHub Flow, Git Flow
• Best practices

Self check:

• Explain the risks of teamwork and how teams can manage those risks.
• Compare synchronous and asynchronous communication and identify which suits a given situation.
• Explain what makes a message clear and actionable and why team decisions should be documented.
• Describe ways to make sure all voices on a team are heard.
• Identify common causes of team conflict.
• Given a conflict scenario, diagnose the likely cause, identify the mode each person is using and recommend a mode with a justification.
• Describe strategies for resolving team conflict.
• Explain the potential benefits of disagreement on a team and how to keep it about ideas rather than people.
• Describe the factors that determine how costly a mistake would be and use them to decide whether a task calls for pairing, swarming, or solo work.
• Describe practices that keep pair programming and swarming effective and the failure modes they guard against.
• Explain what a code review is for and what it should check.
• Explain how to give and respond to code review feedback constructively.
• Explain why teams estimate effort rather than time.
• Describe planning poker and its benefits as a strategy.
• Describe a strategy for understanding an unfamiliar codebase and explain what makes code easier for someone else to understand.
• Define each of the listed Git terms.
• Explain the benefits of version control for a solo developer and for a team.
• Describe the three areas of a Git project and the role each plays in the Git workflow.
• Describe practices for good commits and commit messages, and identify hygiene problems in a given commit history.
• Describe the steps of the solo and team workflows and explain the purpose of each step.
• Explain why merge conflicts occur.
• Explain why teams use branching and explain the trade-offs between trunk-based development and long-lived feature branches.
• Compare GitHub Flow with Git Flow and identify which suits a described project.

Software Construction Practices

Coding standards and documentation topics:

• Coding standards and style guides
• Naming conventions
• Javadoc and what to document

Defensive programming topics:

• Defensive programming: definition, core concepts, key practices
• Checked vs. unchecked exceptions and using exceptions well

Code smells and refactoring topics:

• Code smells, core list
• Refactoring and the test suite as a safety net
• Standard refactorings (core list only)

Self check:

• Explain the purpose of coding standards and style guides.
• Describe Java's naming conventions and explain what makes a name good or poor.
• Identify and fix naming problems in given code.
• Explain the purpose and structure of Javadoc comments.
• Evaluate a given comment as helpful, redundant, or misleading.
• Explain the difference between checked and unchecked exceptions and decide which is appropriate in a given scenario.
• Describe defensive coding practices.
• Distinguish when to use a defensive check, an assertion, or an exception.
• Describe guidelines for using exceptions well and identify poor exception handling in given code.
• Identify code smells in a given piece of code and explain why each is a problem.
• Describe an appropriate refactoring for an identified smell.
• Explain how a test suite supports refactoring.
• Explain why a refactoring and a bug fix belong in separate commits.