Software Construction (MIT 6.1020 / Stanford CS107

You need to sign in or sign up before continuing.

reading · we frame, you read MIT or the canonical taught · we author, no canonical fits ↺ spirals back to earlier lessons

Course locked

Complete System Design Case Studies first.

This course unlocks once you've finished its prerequisite. Open prerequisite →

reading · 35 min + ~140 min canonical

Specifications and Abstract Data Types: The Contracts Beneath the Code

Every method you have ever written has a specification. Most of the time it lives only in your head, or half-written in a comment, or implied by the test that happens to exist. Th…

primary MIT 6.1020 Software Construction (OCW)

preview →

reading · 35 min + ~140 min canonical L1

Testing as Engineering: Partitioning, Boundaries, and Coverage

Most people write tests the way they clean a room the night before guests arrive: reactively, to satisfy a rule, aiming for a number. "Get coverage up." "Add a test for the bug." …

primary MIT 6.1020 Software Construction (OCW)

after L1 locked

reading · 30 min + ~140 min canonical L1

Property-Based Testing: Let the Machine Find Your Bugs

The previous lesson asked you to partition the input space and hand-pick one clever test per subdomain. Property-based testing asks a sharper question: why are you picking the inp…

primary MIT 6.1020 Software Construction (OCW)

after L2 locked

reading · 35 min + ~140 min canonical L1

Systematic Debugging and Refactoring: Changing Code Without Fear

Two activities dominate the actual working life of an engineer, and neither is "writing new code": you spend your days finding out why existing code is wrong (debugging) and chang…

primary MIT 6.1020 Software Construction (OCW)

after L3 locked

reading · 35 min + ~140 min canonical L1

Correctness in Practice: Immutability, Concurrency, Code Review, and Technical Writing

The last lesson of Software Construction gathers the practices that keep code correct once it leaves your head and enters the messy real world — where it runs on many threads at o…

primary MIT 6.1020 Software Construction (OCW)

after L4 locked

exercise reading · 15 min L1

Exercises: Easy (Warm-up)

- [ ] Refactoring Kata: Gilded Rose in Ruby — Refactor the messy conditional logic without changing behavior - [ ] Write RSpec tests for a Ruby class — 100% branch coverage, edge …

after L5 locked

exercise reading · 30 min L1

Exercises: Medium (Core)

- [ ] Refactoring Kata: Tennis Game in Ruby — Refactor scoring logic, apply Replace Conditional with Polymorphism - [ ] Implement property-based testing — Use rantly gem to genera…

after L6 locked

exercise reading · 45 min L1

Exercises: Hard (Stretch)

- [ ] Refactoring Kata: Trip Service in Ruby — Break dependencies for testability, introduce seams - [ ] Build a mutation testing report — Use mutant gem on a Ruby project, achiev…

after L7 locked

exercise reading · 60 min L1

Mini-Project

- [ ] Build a Ruby gem from scratch — Implement a useful library (e.g., configuration DSL), full test suite (RSpec), CI with GitHub Actions, published to RubyGems, README with usa…

after L8 locked

L10

project reading · 360 min L1

Project: Test Quality Analyzer

Build a Ruby tool that measures test quality for an RSpec test suite: compute line coverage, branch coverage, and mutation testing score (using mutant). Generate a report with rec…

after L9 locked

L11

project reading · 600 min L1

Capstone: Lox Language Interpreter

- [ ] Milestone 1: Scanner — tokenize Lox source into token stream (CI Ch4) - [ ] Milestone 2: Parser — recursive descent parser producing AST (CI Ch5-6) - [ ] Milestone 3: Evalua…

after L10 locked

L12

assessment reading · 56 min L1

Self-Assessment: Software Construction (MIT 6.1020 / Stanford CS107 inspired)

- [ ] What is property-based testing? How does it differ from example-based testing? - [ ] What is mutation testing? What does a mutation score tell you? - [ ] Explain representat…

after L11 locked

12 lessons. Read in order; spiral back when you need to. By the end you'll have used the core ideas twice — once on the abstract, once on something you'll meet at work next week.