{
"cmd": ["babel-node", "$file"],
"selector": "source.js",
"path": "/usr/local/bin:$PATH", // ENV setting for mac users
"quiet": true // get rid of annoying `[Finished in %fs]`
}| title | slug | createdAt | language | preview |
|---|---|---|---|---|
Unit testing Angular.js app with node.js, mocha, angular-mocks and jsdom |
unit-testing-angular-js-app-with-node |
2015-07-05T18:04:33Z |
en |
Majority of search result about unit testing Angular.js apps is about how to do it by using test frameworks that run the tests in a real browser. Even though it's great to be able to test your code in multiple platforms, in my opinion it creates a lot of boilerplate code and makes it hard to run the tests in, for instance a CI-server. |
Lean unit tests with minimal setup
| port module Spelling exposing (..) | |
| import Html exposing (..) | |
| import Html.Events exposing (..) | |
| import String | |
| main = | |
| program | |
| { init = init |
| import json | |
| import boto3 | |
| import paramiko | |
| def worker_handler(event, context): | |
| ALLOWED_HOSTS = [ | |
| 'host1', | |
| 'host2, |
| #!/bin/bash | |
| files=$(git diff --cached --name-only | grep '\.js$') | |
| # Prevent ESLint help message if no files matched | |
| if [[ $files = "" ]] ; then | |
| exit 0 | |
| fi | |
| echo $files | xargs eslint |
| const jsdom = require("jsdom"); | |
| const { JSDOM } = jsdom; | |
| const dom = new JSDOM('<!DOCTYPE html><html><head></head><body></body></html>'); | |
| global.window = dom.window; | |
| global.document = dom.window.document; | |
| // Simulate window resize event | |
| const resizeEvent = document.createEvent('Event'); |
| import { IntlProvider } from 'react-intl'; | |
| const language = 'en'; | |
| // Usually messages is declared in another file. | |
| const messages = { | |
| greeting: 'Hello' | |
| } | |
| export const mesg = defineMessages({ | |
| greeting: { | |
| id: 'greeting', |
| #!/bin/bash | |
| # | |
| # You can use `git branch --edit-description` to write a description | |
| # for a branch, but Git provides no simple command to display that | |
| # description. The "easiest" way to see it is via `git config --get | |
| # branch.BRANCH_NAME.description`. | |
| # | |
| # This script automates that process and is meant to be used as | |
| # a Git alias to provide a shorter command for showing the | |
| # description of the current branch. |
| # first: | |
| lsbom -f -l -s -pf /var/db/receipts/org.nodejs.pkg.bom | while read f; do sudo rm /usr/local/${f}; done | |
| sudo rm -rf /usr/local/lib/node /usr/local/lib/node_modules /var/db/receipts/org.nodejs.* | |
| # To recap, the best way (I've found) to completely uninstall node + npm is to do the following: | |
| # go to /usr/local/lib and delete any node and node_modules | |
| cd /usr/local/lib | |
| sudo rm -rf node* |
I’ll assume you are on Linux or Mac OSX. For Windows, replace ~/.vim/ with $HOME\vimfiles\ and forward slashes with backward slashes.
Vim plugins can be single scripts or collections of specialized scripts that you are supposed to put in “standard” locations under your ~/.vim/ directory. Syntax scripts go into ~/.vim/syntax/, plugin scripts go into ~/.vim/plugin, documentation goes into ~/.vim/doc/ and so on. That design can lead to a messy config where it quickly becomes hard to manage your plugins.
This is not the place to explain the technicalities behind Pathogen but the basic concept is quite straightforward: each plugin lives in its own directory under ~/.vim/bundle/, where each directory simulates the standard structure of your ~/.vim/ directory.
