2D — Engineer It

Build it the way professional developers do: designed, tested, and version-controlled properly.

This Level Is for You If…

You're confident with classes (or your language's equivalent), and they feel natural.
Your code usually works, and now you want it to be well-built.
You want to learn the habits that separate working code from well-engineered code.

What You'll Build

A program from the problem menu (calculator-type tool, quiz engine, or simple tracker) with a real object-oriented design: multiple classes that work together. It's backed by automated tests and built on a git branch.

Your project folder will look something like this (file names follow your language's conventions):

2_quiz_engine/
├── README.md
├── main.py              ← your classes and main program
└── tests/
    └── test_quiz.py     ← your automated tests

Requirements Checklist

Your finished project must include all of these. (Ticking the boxes is just for you, it doesn't save.)

Everything on the 2B list
At least two classes that interact (e.g. a Quiz that holds Question objects), sketched before coding
Automated tests in a tests/ folder, using your language's standard test tool (for Python, unittest): at least 8 tests, all passing, and your README explains how to run them
Developed on a branch (e.g. dev), merged into main at CP3 through GitHub Desktop
One mentoring session with a 2A student, logged in your README: who, what they were stuck on, and how you helped without writing their code
AI Collaboration section filled in

On AI and tutorials: fine to use, as long as your AI Collaboration section records what came from them. That includes tests. If AI wrote a test, you should still be able to say what it checks and why.

Not in this unit: reading and writing files, or splitting your code across multiple files. Those are coming in Unit 3, so keep your program in one main file for now.

Your mentoring session

Partway through the project, your teacher will pair you with a 2A student. Spend some time helping them get unstuck, then log it in the Mentoring Log section of your README.

Your job is to ask questions, not to type. Try "What do you expect this line to do?" and "What did it actually do?" If you take the keyboard, you've taken over.

Make your log specific. "Helped with loops" isn't enough. "Asked what the loop's last value would be, and they found the off-by-one themselves" is.

Checkpoints at 2D

Checkpoint	What it looks like at 2D
CP1	Pitch; pseudocode; a class sketch (a box for each class with its attributes and methods, and arrows showing how they connect); `dev` branch created
CP2	Classes working together; at least 4 automated tests passing; mentoring session scheduled or done
CP3	All tests passing; `dev` merged into `main`; mentoring logged; shown to a peer

Remember to start each checkpoint commit with CP1:, CP2: or CP3:, and push before your teacher calls you up.

Class sketch: draw it on paper and add a photo to your README, or type it out as text boxes. Either works, as long as someone could understand your design from the sketch alone.

Test tool: agree on your test tool with your teacher at CP1. For Python that's unittest, as in the examples below. Other languages have their own standard tool.

Setting up your dev branch (CP1)

In GitHub Desktop, click Current Branch at the top, then New Branch.
Name it dev and click Create Branch. Leave it based on main.
Click Publish branch so it's on GitHub too.
From now on, check that Current Branch says dev before you commit.

Writing and running your tests (Python example)

Your test file goes in tests/. For Python, its name has to start with test_. A tiny example:

import unittest
from main import Question

class TestQuestion(unittest.TestCase):
    def test_correct_answer_is_marked_right(self):
        q = Question("Capital of BC?", "Victoria")
        self.assertTrue(q.check("victoria"))

if __name__ == "__main__":
    unittest.main()

To run all your tests, open a terminal in your project folder (the one with main.py in it) and run:

python -m unittest discover -s tests -v

Tests running your whole program? When a test imports main.py, Python runs everything in it, including your menu loop. Put the line that starts your program inside if __name__ == "__main__": so it only runs when you run main.py directly. Other languages have an equivalent check.

Merging dev into main (CP3)

Commit and push everything on dev first.
Click Current Branch and switch to main.
Click Current Branch again, then Choose a branch to merge into main. Pick dev, and click Create a merge commit.
Click Push origin.

Got a merge conflict? Don't panic, and don't delete anything. Put a hand up and your teacher will walk through it with you.

When You're Stuck

Your language's test-tool docs are your main reference. For Python, that's the unittest docs.
If a class is getting big, it's probably two classes.
If tests are hard to write, your functions may be doing too much at once. Split them up. (A method that both asks for input and does the math is hard to test. Keep those separate.)
For branching, GitHub Desktop's Current Branch menu handles create, switch, and merge.

Done Looks Like…

Another developer could clone your repo, run your tests with one command, see them pass, and understand your design from the class sketch alone. Your commit history shows a real branch-and-merge workflow.