I strongly believe that fast iteration cycle is important for productivity. In programming fast iteration means: how quickly can I go from finishing writing the code to testing it. That’s why I don’t like languages that compile slowly: slow compilation puts a hard limit on your iteration cycle.
That’s a general principle. How does it translate to actions?
I’m glad you asked.
Simulated errors
I’m writing a web app and some code paths might fail e.g. server returns an error response.
When that happens I want to display an error message to the user. I want to test that but server doesn’t typically return errors.
I can modify the server to return error and restart it but in a compiled language like Go it’s a whole thing.
Instead I can force error condition in the code. Because web dev typically offers hot reload of code, I can modify the code to pretend the request failed, save the code, reload the app and I’m testing the error handling.
To make it less ad-hoc another strategy is to have debug flags on window object e.g.:
window.debug.simulateError = false
Then the code will have:
try {
if (window.debug.simulateError) {
throw Error("fetch failed");
}
let rsp = await fetch(...);
}
That way I can toggle window.debug.simulateError in dev tools console, without changing the code.
I have to repeat this code for every fetch(). More principled approach is:
async function myFetch(uri, opts) {
if (window.debug.simulateError) {
throw new Error("featch failed");
}
return await fetch(uri, opts);
}
To go even further, we could simulate different kinds of network errors:
- Response.ok is false
- response is 404 or 500
- failed to reach the server
We can change simulateError from bool to a number and have:
async function myFetch(uri, opts) {
let se = window.debug.simulateError;
if (se === 1) {
// simulate Response.ok is false
return ...;
}
if (se === 2) {
// simulate 404 response
return;
}
if (se === 3) {
// simulate network offline
}
return await fetch(uri, opts);
}
Start by show dialog
Let’s say I’m working on a new dialog e.g. rename dialog. To get to that dialog I have to perform some UI action e.g. use context menu and click the Rename note menu item.
Not a big deal but I’m still working on the dialog so it’s a bit annoying to repeat that UI action every time I move the button to the right, to see how it’ll look.
In Svelte we do:
let showingRenameDialog = $state(false);
function showRenameDialog() { showingRenameDialog = true; }
{#if showingRenameDialog}
<RenameDialog ...></RenameDialog>
{'if}
To speed up dev cycle:
let showingRenameDialog = $state(true); // show while we're working ont
While I’m still designing and writing code for the dialog, show it by default. That way app reloads due to changing code won’t require you to manually redo UI actions to trigger the dialog.
Ad-hoc test code
Let’s say you’re writing a non-trivial code server code to process a request. Let’s say the request is a POST with body containing zip file with images which the server needs to unzip, resize the files, save them to a file system.
You want to test it as you implement the logic but iteration cycle is slow:
- you write the code
- recompile and restart the server
- go through UI actions to send the request
Most of the code (unpacking zip file, resizing images) can be tested without doing the request. So you isolate the function:
func resizeImagesInZip(zipData []byte) error {
// the code you're writing on
}
Now you have to trigger it easily. The simplest way is ad-hoc test code:
func main() {
if true {
zipData := loadTestZipFileMust()
resizeImagesInZip(zipData);
return;
}
}
While you’re working on the code, the server just runs the test code. When you’re done, you switch it off:
func main() {
if false {
// leave the code so that you can re-enable it
// easily in the future
zipData := loadTestZipFileMust()
resizeImagesInZip(zipData);
return;
}
}
Those are few tactical tips to increase dev cycles.
You can come up with more such ideas by asking yourself: how can I speed iteration cycle?