API Maker
The backend engine for the AI era
Test casesEpisode 37 5:48 12 chapters October 2026
A custom API that works today can break tomorrow with one character. Give Cart Quote four tests with mocks instead of a database, watch one run find a real bug before a customer does, fix it, run them all, see every line the tests ran, and run the same tests with npm run test in your CI.
In the playlists The complete course Testing & debugging
A custom API that works today can break tomorrow, with one character. In this video, Cart Quote gets four tests, with mocks instead of a database ; one run finds a real bug, and the coverage shows every line the tests ran.
Testing a backend usually means a test database, with its fixtures to keep up to date, a mocking library for each framework, a runner to set up in CI, and a coverage tool for each language. With API Maker, tests run on the server, in the sandbox of the account, with the same g as the code. Any call of g dot sys can be mocked, from a dialog or in the code.
One button, or npm run test, runs them, and every run tells which lines ran, in eight languages. In this video : the Test Cases page, a test case and its mocks, four tests, a run that finds a bug, the fix and Run all, the coverage, the same run in a terminal, and tests in every language.
Test Cases is on the dashboard. On the left, every test case of the account ; in the middle, the code of one ; on the right, the run. There is none yet.
New. The test case is named Cart Quote, its kind : a custom API, and the custom API is Cart Quote : the quote of a cart at the checkout, from video thirty eight. Cart Quote reads the prices of products from MongoDB, and coupons from MariaDB. A test should not depend on that data. The Mocks tab starts with the calls tests fake most. A blank mock reads as a sentence : when the test calls db dot query, only when its query is for the collection products, answer with these three products.
The same mock, written for the code, is right below. A second one : db dot query, this time, for the coupons, answered with WELCOME5, five percent. Save. The test case has its code : TypeScript by default, or any language of the picker. Its mocks, two, are next to the button that opens them.
Four tests. runCustomApi runs the code of Cart Quote inside the test, and its calls of g dot sys meet the mocks. A cart of exactly one hundred and fifty ships for free. A small cart pays shipping. WELCOME5 takes five percent, and g dot sys dot test dot calls says the mocks answered twice. The last test brings its own mock : no coupon is found, so the API must refuse.
Save. Run. Three tests pass, one fails : a cart of one hundred and fifty ships for free. What came, next to what was expected : shipping nine point nine, a total of one hundred and fifty nine point nine. The rule of Cart Quote says : shipping is free when the subtotal is greater than one hundred and fifty. The promise was : from one hundred and fifty. In video thirty eight, a customer found this bug.
Here, a test found it first, in a few milliseconds, without a database.
The code of Cart Quote : Test API, Code. Line twenty two. Greater or equal. Save. The menu, and Test Cases : the test case is still red, from the last run. Run all runs every test case of the account : four of four pass.
The coverage of the run : every line ran, in two files : Cart Quote, and its test case. Every line of Cart Quote ran : the four tests reach every branch, the coupon and the shipping rule. A line that no test reaches is red. And back in the list, the test case shows its result and its coverage above its code.
The folder of the local client, on a laptop, runs the same tests : npm run test. The tests run on the server, and every step prints as it happens, with the coverage of each file. The exit code is zero when everything passed, one when a test failed, two when the run did not complete : a CI job needs nothing more. And coverage slash lcov dot info marks the lines in VS Code and WebStorm.
A test case can be written in TypeScript, Python, PHP, C sharp, Go, Rust, Java or Kotlin, each the way its own test tools name tests. A test of one language can run a custom API of another : the mocks answer it there too. And every language counts its own lines.
Test cases are files in git, next to the code they test, so a person or an AI assistant writes them like any other file. A mock is a plain value anyone can read, or a function of the test, and it can fail a call or answer only a few of them. And the same command runs on a laptop and in CI.
To sum up. Tests run on the server, with the same g as the code. Every call of g dot sys can be mocked. A run shows what was expected next to what came. Coverage marks every line that ran. npm run test runs them from a terminal and in CI. Next : debugging, from a failing call to the line that broke. API Maker. Build faster, spend smarter, deliver better.
Length 8:32Debugging
Length 7:04Test cases in depth
Length 6:13Coverage
Length 5:45API Testing