AP CSP Unit 1 Practice: Diagnose Weak Topics and Master Creative Development

Question: A student is building a study app and asks a classmate to test it. The classmate finds a bug that the student missed. What is the main benefit of this collaboration?

Choices: A) The student doesn't have to do any work · B) Two people working together catches errors one person missed ✓ · C) The classmate gets credit for the project · D) The student's code becomes longer

Explanation: Fresh eyes on a program often spot logic gaps the author no longer notices. Testing with a partner is collaboration because both people contribute observations, not because work disappears. On the AP exam, collaboration items reward feedback loops and shared debugging rather than dividing credit. The correct answer focuses on catching mistakes early, which saves time before the Create Task deadline.

Question: A student writes all their code first, then tests it once at the end. They find 5 bugs at the same time. Which step of the program development process did they skip or shorten?

Choices: A) Investigate · B) Design · C) Iterating and testing throughout development ✓ · D) Document

Explanation: The development cycle is meant to loop: build a slice, test it, fix issues, then continue. Saving every test for the last hour stacks failures and makes each bug harder to trace. College Board language calls that shortened iteration and testing — not skipping documentation alone. Students who test continuously usually finish with fewer surprise crashes on submission day.

Question: A student builds version 1 of their program (one feature, working), tests it, then adds a second feature for version 2. Which process is the student following?

Choices: A) One-time development · B) Iterative development ✓ · C) Documentation · D) Debugging

Explanation: Each version adds capability while keeping the program runnable — that is the hallmark of iteration. Debugging might happen inside a cycle, but the overall pattern here is planned growth across versions. One-time development would mean no structured retest between features. AP prompts often describe version numbers or “first working build” language when they want iterative development as the answer.

Question: A student tests their program only with the inputs they expect users to enter. What is the main weakness of this strategy?

Choices: A) The program will run slower · B) It may not catch errors caused by edge or invalid inputs ✓ · C) The program won't work · D) Documentation gets harder

Explanation: Happy-path testing proves the program works when users behave perfectly — real users rarely do. Blank fields, zero values, and out-of-range numbers are common on Create Task demos and exam scenarios. Edge and invalid cases are where crashes and wrong scores usually hide. A strong test plan lists those cases before coding the fix, not after the teacher finds them.

Question: A student writes a procedure called checkAnswer and adds the comment // This adds 1. What's the problem with this comment?

Choices: A) Comments shouldn't be added to code · B) The comment is too long · C) The comment doesn't explain the purpose — it just describes one line ✓ · D) The comment is in the wrong place

Explanation: Comments should help a reader understand intent: why the score changes, what rule is enforced, or what state is updated. Repeating the syntax (“adds 1”) adds no insight beyond reading the line itself. Graders and future teammates cannot tell whether the increment is for streaks, penalties, or partial credit. Purpose-driven comments also make Create Task written responses easier because you already named the design decision in code.

Question: Which action is the best example of collaboration in computing?

Choices: A) Copying a classmate's code · B) Submitting a tutorial project · C) Asking a classmate to test your app and explain what confused them ✓ · D) Ignoring user feedback

Explanation: Collaboration requires communication and shared improvement of the product, not shared answers on paper. Usability testing with a partner surfaces confusion you normalized while building. Copying bypasses the thinking the AP course measures. When you can describe what your tester struggled with, you have evidence of a real collaborative loop.

Question: A team of 4 students is building a quiz app. Which division of work best shows healthy collaboration?

Choices: A) One student writes all the code; the others wait · B) Each student writes a separate piece, then they combine ✓ · C) All four type at the same keyboard · D) Each student writes the same code

Explanation: Healthy teams split modules — scoring, question bank, UI — then integrate and test together. Waiting on one author creates bottlenecks and hides who understands which part. Pairing at one keyboard can help for short bursts but is not a full project plan for four people. The AP course rewards clear roles plus combined review before submission.

Question: A classmate finds a bug in your program. What's the strongest response from a collaboration standpoint?

Choices: A) Get defensive and ignore them · B) Thank them, ask exactly what they saw, and fix the bug ✓ · C) Delete the bug-finder's comment · D) Submit the program anyway

Explanation: Specific reproduction steps turn a vague “it's broken” into a fix you can verify. Thanking the reporter keeps feedback coming on the next iteration. Ignoring or deleting feedback breaks trust and leaves the defect in production. Strong collaborators treat bug reports as data, not criticism.

Question: A programmer realizes during testing that their original design had a flaw. What is the best next step?

Choices: A) Add documentation explaining the flaw · B) Submit the project as-is · C) Return to the design step and fix the layout ✓ · D) Start over from scratch

Explanation: The program development process is explicitly non-linear: testing informs design. Documenting a flaw without fixing it leaves users stuck with the same bad flow. Starting from scratch wastes working pieces that still function. Returning to design to adjust structure is normal professional practice and matches AP wording on iteration.

Question: Which step of program development is usually skipped or shortened when students rush?

Choices: A) Writing code · B) Investigating user needs ✓ · C) Submitting the project · D) Naming variables

Explanation: Investigation asks who the user is, what problem matters, and what success looks like. Without that clarity, code solves the wrong task elegantly. Students under time pressure often open the editor first because it feels productive. Exam prompts about “purpose” or “target user” are testing whether investigation happened at all.

Question: A student says "my program is finished." What step should still happen before they can fully say it's done?

Choices: A) Documentation ✓ · B) Investigation · C) Buying the program · D) Erasing the code

Explanation: Documentation captures how the program works, why choices were made, and how to maintain it. Investigation and design already happened earlier in the cycle for a finished feature set. Erasing code would destroy the artifact. Create Task rubrics expect you to explain segments clearly — that is much faster when documentation exists from development.

Question: Which approach best demonstrates iterative development?

Choices: A) Write the whole program perfectly on the first try · B) Build version 1 (one feature), test it, then add more features one at a time ✓ · C) Skip testing to save time · D) Write all code first, then test at the end

Explanation: Iteration means each pass leaves you with something testable, not a pile of untested code. Option D is the anti-pattern the course warns against. Perfect first drafts are unrealistic on timed tasks. Versioned feature adds give you checkpoints for screenshots, test evidence, and written responses.

Question: A classmate gives feedback: "I don't like it." How can the programmer make this feedback useful for the next iteration?

Choices: A) Ignore the feedback · B) Ask the classmate to be specific about what they didn't like ✓ · C) Delete the program · D) Add a new feature unrelated to the feedback

Explanation: Vague dislike does not tell you whether the layout, wording, or logic failed. Follow-up questions turn opinion into a change list you can implement and retest. Random new features may ignore the actual pain point. AP scenarios about user feedback assume you can refine based on concrete observations.

Question: A programmer builds, tests, finds a bug, fixes the bug, and tests again. Then they add a new feature and repeat the cycle. How many iterations have they completed?

Choices: A) 1 · B) 2 ✓ · C) 3 · D) 0

Explanation: One iteration is a full build-test-refine pass on the current feature set. The first cycle ends after the bug fix is verified; the second begins when a new feature is added and tested. Counting partial edits inside a single cycle as separate iterations is a common trap on MCQs. Watch for “add a new feature and repeat” as the signal for a second iteration.

Question: A program crashes when the user enters a blank answer. What type of test case revealed this bug?

Choices: A) Normal case · B) Edge case · C) Invalid case ✓ · D) Repeated case

Explanation: A blank response is not a typical “happy path” input the designer expected. Invalid cases probe inputs outside allowed rules — empty strings, letters in numeric fields, etc. Edge cases sit at boundaries of valid data (first question, max score). Naming the case type correctly helps you write Row 6 test descriptions on the Create Task.

Question: Which of the following is the best example of an edge case for a quiz with 20 questions?

Choices: A) The user answers question 10 correctly · B) The user answers question 1 (the first one) ✓ · C) The user types a normal answer · D) The user closes the app

Explanation: Edge cases stress boundaries: first index, last index, minimum score, maximum score. Question 10 is mid-range, not a boundary. Closing the app might be an interruption scenario but not an input-boundary test. Lists and loops often fail at index 0 or length − 1, which is why question 1 matters.

Question: A student writes "I tested my program and it worked" in their Create Task response. Why does this lose points on the rubric?

Choices: A) The student didn't actually test · B) The rubric requires two specific procedure calls with different arguments and outputs ✓ · C) Testing isn't important · D) The response is too long

Explanation: Row 6 asks for evidence: procedure name, arguments passed, and observed results. A blanket claim gives graders nothing to verify against your video. Testing absolutely matters — the rubric just demands precision. Write tests the way you would teach a partner to reproduce a bug: concrete inputs and outputs.

Question: Which is the better comment for a line that increases a score after a correct answer?

Choices: A) // This adds 1 · B) // Increase score after a correct answer ✓ · C) // Score code · D) // Numbers

Explanation: Option B states the rule the reader needs: score rises when the answer is correct. Option A only restates the arithmetic the line already shows. Labels like “score code” or “numbers” do not explain behavior. On exam day you may need to quote comments when describing abstractions — write them so they stand alone.

Question: Why does documentation matter for the AP CSP Create Task?

Choices: A) It makes the program run faster · B) It helps the student write stronger exam-day responses about their code ✓ · C) It changes the rubric · D) Documentation doesn't matter

Explanation: Written responses ask you to identify procedures, parameters, and logic in your own project. If you documented while building, you already named those pieces in plain language. Documentation does not change scoring rules or execution speed. Skipping it forces you to reverse-engineer your code under time pressure in May.

Question: A student adds 10 comments to their code, but each one just repeats what the line does ("this is a loop", "this is a variable"). What's wrong with this approach?

Choices: A) There are too many comments · B) The comments are clutter — they don't explain decisions or purpose ✓ · C) Comments are not allowed · D) The code won't run

Explanation: Noise comments make real warnings harder to spot when you skim before submitting. The AP course wants rationale: why this loop, why this variable scope, why this threshold. Comments never affect whether code compiles. Quality beats quantity — two purposeful notes outperform ten redundant ones.

Question: A student is 6 hours into their Create Task with a quiz app. During final testing, the score doesn't reset when a new round starts. They have 3 hours left. What should the student do first?

Choices: A) Submit the project as-is · B) Investigate the score reset bug and refine the program ✓ · C) Add 10 more questions · D) Delete the score feature entirely

Explanation: A broken core loop undermines the whole demo even if questions look polished. Three hours is enough to trace variables, reset state on “new round,” and re-test edge cases. Adding questions expands scope while the bug remains. Removing scoring avoids the problem instead of solving it — graders still expect working behavior.

Question: A classmate says the program is "confusing." What's the most useful next step?

Choices: A) Ignore the feedback · B) Ask the classmate what specifically confused them ✓ · C) Add documentation · D) Submit the project

Explanation: “Confusing” might mean hidden buttons, unclear instructions, or inconsistent scoring — you cannot guess which. A two-minute follow-up interview targets the next iteration. Documentation helps after you know what to explain, not before. Shipping without clarification risks the same usability failure on review day.