- "Write tests. Not too many. Mostly integration."
- Integration tests strike a great balance on the trade-offs between confidence and speed/expense. This is why it's advisable to spend most (not all, mind you) of your effort there.
- biggest thing you can do to write more integration tests is to stop mocking so much stuff
- When you mock something you're removing all confidence in the integration between what you're testing and what's being mocked.
function createHandler(handler: typeof Handler, params: string[]) {
var obj = new handler(params);
return obj;
}
var h = createHandler(Handler, ['hi', 'bye']);
In things/index.js,
export {default as ThingA} from './ThingA'
export {default as ThingB} from './ThingB'
export {default as ThingC} from './ThingC'
Then to consume all the things elsewhere,
import * as things from './things'
The “vanilla” store implementation you get by calling createStore only supports plain object actions and hands them immediately to the reducer.
However, if you wrap createStore with applyMiddleware, the middleware can interpret actions differently, and provide support for dispatching async actions. Async actions are usually asynchronous primitives like Promises, Observables, or thunks.
Definition 4: This value: in JavaScript this value is dynamically scoped, unless used in an arrow function.
That’s correct: as we know, the value of this is determined and provided exactly by the caller.
function produce() {
console.log(this.x);
}
const alpha = {produce, x: 1};
const beta = {produce, x: 2};
const gamma = {produce, x: 3};
console.log(
alpha.produce(), // 1
beta.produce(), // 2
gamma.produce(), // 3
);