Christopher Swasey endash

Your Momma So Fat All Her Tests Are Integration Tests

No two engineers can agree what is or is not a unit test, an integration test, or an acceptance test, or the difference between them. This is one of the immutable laws of the universe. So, in the grand tradition of my craft, I'm going to stir the pot further by throwing my own take into the ring.

The key to grokking unit and integration tests, in my opinion, is not to think of them individually, as distinct things with their own definitions that can be known on their own terms. Instead, I think of them as being related by a recursive definition, holisitcally. On their face, integration tests are, intrinsically, more complex and fragile than unit tests. They combine multiple moving pieces into one. Oftentimes, they need fixtures or some encompassing test harness, or are otherwise awkwardly contorted to fit environmental constraints. It stands to reason that anything that lets us reduce the need for integration tests without sacrificing coverage is a g

A man asked a novice software engineer to build him a shed. He came back the next day and saw that the engineer had poured the concrete foundation, and it looked pretty good. He came back each day, and each day the shed was looking better and better, and when it was done at the end of the week the man was quite pleased.

The next week, the man asked the engineer to build a treehouse for his kids. He came back the next day, and saw that a mass of scaffolding had been erected, some idle workers were standing around, and large plywood frames were being hoisted up into the canopy.

"What's going on here?" the man asked the engineer, in bewilderment.

"We're getting ready to pour the foundation," the engineer replied.

Code Design for Managers

There is, in software development, a tension between external pressures to turn out new features and products, and the internal need to maintain high professional standards and minimize technical debt. It can be hard, from the outside, to see the business value in things like refactoring, architectural planning, high standards for code design, and the like, if they seem to extend the development timeline for some new, important piece of software. Some, like code design, might seem purely a matter of aesthetics, if it all leads to the same place, in the end. This perspective is short-sighted, and is quite often fatal or at least highly detrimental to whatever business interests were supposedly being served by undervaluing engineering professionalism.

You might be thinking: “Well, maybe code design is ultimately a subjective thing, like those godless heathens who use tabs to indent their code, or maybe only perfectionists who are impossible to please should, or do, care about it.” W

The problem

In some situations it is beneficial to force an observable to resolve subscriptions asynchronously, via use of the observeOn operator. Failing that, it is at least possible to force an observable to resolve asynchronously. The issue from an Angular perspective is that we usually want our subscribe callback to run in the Angular zone, otherwise change detection won't automatically kick off. Additionally, inside an asynchronous observer callback setTimeout does not run in the app zone, eliminating a potentially obvious solution. To code defensively, one might use NgZone.run wherever there's a possibility that an observable is async. Unfortunately, this has the knock-on effect of causing errors if the observable is not async. To prevent those errors observables can be uniformly forced async, with NgZone used in the subscribe callback, resulting in uniform, proper behaviour. These measures have a not insubstantial technical cost.

I am not presently aware of a way to ensure that cal

Note: This implementation is based on RxJS 4.0

⚠️ potentially buggy do not use in production ⚠️

Use case

Heavy use of observables can result in many components with duplicate boilerplate code for subscribing to an @Input observable and assigning the value(s) to another property for use in the template. This might also involve juggling property names if you want to use the same semantic naming in both the component's API and template. Additionally, some defensive boilerplate is necessary to guard against

	<!DOCTYPE html>
	<html>
	<head>
	<title>mask-image bug demo</title>

	<style>
	div {
	width: 24px;
	height: 24px;
	}

	<!DOCTYPE html>
	<html>

	<head>
	<meta charset="utf-8">
	<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
	<title>Normal Plot</title>
	<meta name="description" content="">
	<script src="http://d3js.org/d3.v3.min.js" charset="utf-8"></script>
	<style type="text/css">

	/**
	* Creates a pipe suitable for a RxJS observable:
	*
	* @View({
	* template: '{{ someObservable \| rx}}'
	* pipes: [RxPipe]
	* })
	*
	* Originally written by @gdi2290 but updated for 2.0.0.alpha-35 and use AsyncPipe
	* (Soon the Angular team will be using RxJS natively and this pipe will be

	let opt: ((NSColor) -> Bool)? = nil
	let nonOpt = {(aColor: NSColor) in return true }
	let coalesced = opt ?? nonOpt

	let opt: ((NSColor) -> Bool)? = nil
	let coalesced = opt ?? {(aColor: NSColor) in return true }