glenjamin

services:
  postgres:
    image: "postgres:16.3"
    environment:
      POSTGRES_HOST_AUTH_METHOD: trust
      PGUSER: postgres # make it so `exec psql` works
    ports:
      - "127.0.0.1:5432:5432"

glenjamin

var mysql = require('mysql');

var pool = mysql.createPool('mysql://localhost');

inTransaction(pool, function(db, next) {
    db.query("DELETE * FROM stuff", function(err) {
        if (err) return next(err);

        db.query("INSERT INTO stuff VALUES (1,2,3)", function(err) {
            return next(err);

glenjamin

Honeycomb env-switching bookmarklet

This will toggle between the staging and production environments by default. Adjust the naming if that isn't what yours are called.

Setup

Create a bookmark named "Honeycomb Environment Switcher"

Set the target URL as the following, which is the content from full.js with newlines and indents removed.

glenjamin

{
  "absolute": true,
  "item": [
    {
      "text": "",
      "value": [null, "2024-12-25T00:00:00Z"]
    }
  ]
}

glenjamin

Here's neat testing trick I've just come across.

I've got an HTTP client that makes requests to https://accounts.google.com.

So I create a fake HTTP server:

srv := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
/// ...
})

glenjamin

/*eslint-env browser*/
/**
 * Cribbed from:
 * github.com/facebook/react/blob/master/src/addons/ReactRAFBatchingStrategy.js
 * github.com/petehunt/react-raf-batching/blob/master/ReactRAFBatching.js
 */

var ReactUpdates = require('react/lib/ReactUpdates');

var ReactRAFBatchingStrategy = {

glenjamin

How I do automated tests

There’s a lot of posts out there where people will tell you how to do something. How you must do something in a certain way. How you’re not a real developer unless you do things in this particular way. I hate that sort of post.

I strongly believe that there isn’t such a thing as a best practice. There are effective practices that work well in certain contexts, but might be less effective in other contexts - although I’m pretty confident that some practices aren’t effective in any context. I do, however, think there’s a lot of value to be found in taking a practice that’s successful in one context, and finding ways to adapt or generalise it into more contexts.

So with those caveats out of the way, here’s a post that tries to explain and justify how I personally write my automated tests. These approaches have been shaped over the years by my own experiences but also by the opinions of my colleagues and how well (or not) we’ve seen them work.

The techniques I’m writing about here

glenjamin

/* @flow */

import * as I from "immutable";

/**
 * Define an immutable record intended for holding reducer state
 * @param  spec - the keys and their default values
 * @return a state record factory function
 */
export function defineRecord<T: Object>(

glenjamin

---
driver:
  name: docker
  provision_command:
    - yum -y swap -- remove systemd-container systemd-container-libs -- install systemd
    - systemctl enable sshd.service
    - curl -L https://www.opscode.com/chef/install.sh | bash
  require_chef_omnibus: false
  run_command: /usr/sbin/init
  privileged: true

glenjamin

// The hypothetical <Routing /> component would pass extra props to <App /> to say which route is active

// 1. Wrapped component accepts component class and passes on props plus extras
<Routing
  rootComponent={App}
  propForApp="abc"
  propForApp2="def"
/>
    
// 2. Wrapped component takes children and uses cloneElement to pass extra props