-
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. -
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 (
#!/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")/'' |
// Use Gists to store code you would like to remember later on | |
console.log(window); // log the "window" object to the console |
#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