Mocks That Fail, Count and Compute : Test Cases in 8 Languages and in CI

Intro

0:00 Video thirty seven gave a custom API its first tests. This one goes further : mocks that fail a call like a busy database, mocks that answer a number of calls, mocks that compute their answer, in eight languages, and tests that run from your repository and in CI.

The paths nobody tests

0:18 The bugs that reach production hide in the paths nobody tests. A database that times out once. A retry written months ago, and never run. A mocking library for each language, each with its own rules. And a CI job that tests what the server has, not your commit. With API Maker, a mock fails a call exactly as the API would, for as many calls as you say, a function of the test computes an answer, in each of the eight languages, and npm run test sends the changes of your folder first, so the code you wrote is the code that runs.

0:54 In this video : a custom API with a retry, a mock that fails the call, a mock for one call only, the run, and the lines of the retry, functions as answers, conditions inside objects, every language, a test of one language for an API of another, the whole answer, npm run test from the repository, and CI.

Stock Check and its retry

1:16 Stock Check is a custom API of Calm Home : the units of a product in the warehouses. It reads SQL Server, and adds the quantities. When the database answers five hundred and three, busy, it logs it, and asks once more. Code like this is written once, and its second path is rarely run, until the day it is needed. Its test case has three tests. The first expects the retry : two calls, twelve units, two attempts.

1:46 The second brings its own mock : the warehouse is busy twice, and the API must say so. The third answers with a function of the test. The first test needs mocks : they go in the Mocks tab.

A mock that fails the call

1:59 Test Cases. Stock Check, with its three tests. Its row has a button for its mocks. There are none yet. A blank mock. When the test calls db dot query, with one condition, a query of the inventory, fail with an error. The warehouse is busy, code five hundred and three, for one call. The card says it fails, and the same mock, written for the code, has error, and times.

2:28 A second mock, db dot query, with the same condition, the inventory, answered with two rows : seven units in one warehouse, five in another. The first mock answers the first call, once, then the second one answers. Update.

The run, and the lines of the retry

2:44 Back on Test Cases, Stock Check, and Run. Three of three pass. The first test saw the database fail, then answer : twelve units, in two attempts, and g dot sys dot test dot calls counted two calls. The coverage of the run. Every line of Stock Check ran, the retry among them : the log, and the second attempt. Without a mock that fails, those lines would stay red.

Which mock answers

3:11 Mocks are tried from the top. The first one that matches the call answers, as many times as it says. Then it is used up, and the next one answers. A mock written in the code of a test comes before the ones of the tab, and every test starts with them fresh.

Functions as answers

3:28 A mock can also be a function. As a condition, it gets the argument of the call, and says yes or no. As an answer, it gets the arguments, and what it returns is the answer. What it throws fails the call, like an API would. In TypeScript, it can be async.

Conditions inside objects

3:47 A condition which is an object asks for what it has, inside objects too. This one matches a query of the inventory whose find has this product, whatever else the query asks : a sort, a limit, other filters. A list asks for as many items. And a key set to null asks for no value at all.

Every language

4:08 The same mocks, in Python : error, times, and a lambda. In Go, a func. In C sharp, Mock dot Answer. In Rust, answers, with a closure. Java and Kotlin have answers and whenMatches, and PHP an arrow function. Eight languages, one set of rules.

A test of one language, an API of another

4:28 A test of one language can run a custom API of another. Here a test in Python runs an API written in Go. The API runs in the sandbox of Go, and calls db dot query. API Maker finds the mock, and asks the test for its function, in Python, while the API waits. The answer goes back to Go. The API never knows it was a test.

The whole answer

4:52 A call which asks for the whole answer gets it whole from a mock too. A mock that fails gives success false, the status, and the errors, and nothing is thrown, so the code which reads the status is tested as well.

npm run test from the repository

5:07 The tests are files of the git repository, next to the code they test. Change one in your editor, and run npm run test. It sends the changes of the folder to the server first, waits until the server saved them, then the run starts, and every step prints as it happens. The code you wrote is the code that ran. When npm run start already runs in the folder, it keeps it in sync, and npm run test starts the run at once.

5:36 With no sync, it runs what the server has. A filter runs only the test cases it names, bail stops at the first failure, and json writes the whole result to a file.

In CI

5:49 In CI there is no config file : the job gives three variables, the address of the server, the sync token as a secret, and the account. A fresh clone never synced, so push sends the code of the commit to the server first : the tests of the commit run against the code of the commit. The exit code is zero when everything passed, one when a test failed, two when the run did not complete.

6:13 And the coverage, in lcov, is ready for a coverage service. Point the job at a server for development or tests, never production.

Recap

6:22 Mocks that fail a call, like the API would. Mocks for a number of calls, to test a retry. Functions as conditions and answers, in all eight languages. Conditions that look inside objects. And npm run test, from your repository and in CI. Next : debugging, from a failing call to the line. API Maker. Build faster, spend smarter, deliver better.