- "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.
Probably the only valid reason for using
set enable_seqscan=false
is when you're writing queries and want to quickly see what the query plan would actually be were there large amounts of data in the table(s).
text/html; vimprobtab.sh %s &; test=test -n "$DISPLAY"; needsterminal;
text/html; w3m -I %{charset} -T text/html; copiousoutput;
The first entry tests that X is running, and if it is, it hands the file to vimprobable. The default, however, is determined by the copiousoutput tag. So, in mutt it is just a matter of hitting v to view the attached HTML and then m to send it to mailcap
E. Pinheiro, W. Weber, and L. Barroso. Proceedings of the 5th USENIX Conference on File and Storage Technologies, page 2--2. Berkeley, CA, USA, USENIX Association, (2007)