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

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

// 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

glenjamin

/**
 * Get a promise for a user-selected File object
 */
export function chooseLocalFile(): Promise<File> {
  const input = document.createElement("input");
  input.type = "file";
  input.accept = "application/json";
  return new Promise((resolve) => {
    input.addEventListener("change", () => {
      const file = input.files[0];

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

Confident UI development through better feedback

Abstract

When you make a change to user-interface code, how do you know if it does what you expect? How long do you have to wait between typing some code, hitting refresh, and then seeing the result?

There are popular tools to speed up this refresh cycle, but what about user interaction or multiple component states? Even with auto-refresh or hot code reloading you'll usually still have to click on a button to check if your animations are working correctly.

I'll show you how you can get an even better level of immediate feedback from changes. One that lets you see the variety of possible states and interactions your components have all at the same time. This can vastly improve our experiences when building interactive web applications.

glenjamin

(function ElmNativeWrapper(name, actualNativeModule) {
  var initialised = false;
  window[name] = {
    init: function(appname) {
      // Could use Object.keys(window) here to try and detect if the name is wrong
      
      window[munge(appname) + "$Native_" + name] = actualNativeModule();
      initialised = true;
    }
  }

glenjamin

var getComputedStyle = require('computed-style');
var fontStyles = ['font-family', 'font-size', 'font-weight', 'font-style'];

module.exports = function getFontStyles(domElement) {
  return {
    element: domElement,
    styles: extractFontStyles(domElement)
  }
}

glenjamin

#!/bin/sh

set -e

# !!!!
echo "*** REPLACE this with the line which builds docs"
# !!!!

echo "*** Docs built ***"
tmpdir=`mktemp -d /tmp/gh-pages-build.XXXXXX`

glenjamin

var Immutable = require('immutable');
var FooRecord = Immutable.Record({ a: 1, b: 2 }, 'foo');
Immutable.is(new FooRecord(), new Immutable.Map({a: 1, b: 2}));
// => true