Book a trip to Saturn. Then count the bugs.
Space Tours is the sandbox I teach on. Two versions are running. One works. The other has bugs planted in it on purpose. Finding them is the exercise.
Stellar Command
The reference build. Book a seat to Mars, change it, cancel it. This is what the API is supposed to do.
Open the booking app →VOID//TERMINAL
Same booking system, deliberate defects, and a different look so the two builds are never confused. Some bugs are obvious. Some only show up if you try the thing nobody tries.
Open the broken one →Both run on free hosting and go to sleep when nobody is using them. First load takes up to a minute.
Not every defect files a ticket.
Hunting the planted bugs is the patient half of this lab. Space Tours Defense is the other half: same universe, no booking form, a liner full of tourists behind you and eight stops between Earth orbit and Neptune. It runs in the browser, and the only thing to file at the end is a high score.
Play Space Tours Defense →
Some of them arrive in formation.
Why it exists
APIs are hard to explain. You can put a request and a response on a slide, but it stays abstract until someone sends one and watches what comes back.
So I built something to point at. Space Tours is a whole system, not a snippet: a REST API, a database behind it, and a booking UI in front. Students see the same booking from both ends and follow what happens in between. Fork it and the database comes too, with a guide, which is where a lot of people first learn to work with one.
The broken build looks different on purpose. Different name, different colours, same system underneath. That is a lesson in itself: environments and versions are something a tester has to keep straight every day, and mixing them up is easier than it sounds.
Swagger is where beginners usually stall. A public API to take apart fixes that, without the fear of breaking a codebase at your work.