Skip to content

Instantly share code, notes, and snippets.

Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
@dev-rice
dev-rice / go_test_color
Last active January 24, 2019 17:01
Run go tests automatically (now with COLOR!)
#!/bin/sh
# TODO make the sed to color 'ok' only color 'ok '
go test ./... $@ | sed ''/PASS/s//$(printf "\033[32mPASS\033[0m")/'' | sed ''/FAIL/s//$(printf "\033[31mFAIL\033[0m")/'' | sed ''/ok/s//$(printf "\033[32mok\033[0m")/''
  1. When first writing code where you call a function that returns an error make it panic(err). This is like a TODO in code because you will catch it in a diff.

  2. https://github.com/rosenhouse/counter-demo/blob/master/server/main.go#L18 All dependencies are in main. There are no inter package dependencies so if you look at a dependency graph it would be a wide tree with depth of 1.

    One way to achieve this is to have an exported struct that depends on unexported interfaces. This makes it so you don't have to have dependencies between files

    package handlers
    
    import (
@dev-rice
dev-rice / 0_reuse_code.js
Created November 17, 2016 14:19
Here are some things you can do with Gists in GistBox.
// Use Gists to store code you would like to remember later on
console.log(window); // log the "window" object to the console
@dev-rice
dev-rice / unit_testing.md
Last active August 3, 2016 01:06
Guidelines for Unit Testing

#Make each test orthogonal (i.e., independent) to all the others Any given behaviour should be specified in one and only one test. Otherwise if you later change that behaviour, you’ll have to change multiple tests. The corollaries of this rule include:

#Don’t make unnecessary assertions Which specific behaviour are you testing? It’s counterproductive to Assert() anything that’s also asserted by another test: it just increases the frequency of pointless failures without improving unit test coverage one bit. This also applies to unnecessary Verify() calls – if it isn’t the core behaviour under test, then stop making observations about it! Sometimes, TDD folks express this by saying

#Have only one logical assertion per test Remember, unit tests are a design specification of how a certain behaviour should work, not a list of observations of *everything *the code happens to do. *

#Test only one code unit at a time